httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@avron.ICS.UCI.EDU>
Subject httpd security holes
Date Sun, 12 Mar 1995 08:27:54 GMT
> On Sat, 11 Mar 1995, Robert S. Thau mentioned two paches in apache-pre:
>>   patch.security-CERT --- CERT security patch
>>   patch.security-NCSA --- NCSA security patch
> 
> I changed httpd.h from
> 
> #define MAX_STRING_LEN HUGE_STRING_LEN
> 
> to
> 
> #if defined(MEMHOGBUTSECURE)
> #define MAX_STRING_LEN HUGE_STRING_LEN
> #else
> #define MAX_STRING_LEN 256
> #endif
> 
> and added a comment to the top of the Makefile appropriately.


I'd rather not have this in the server, for a couple reasons.

 1) It does not completely fix the scribble bug -- I have no idea why
    CERT thinks it would, but if you look at the code carefully the
    temporary variable needs to be MAX_STRING_LEN+HUGE_STRING_LEN in
    order to hold a maximal replacement.  Even with that, it is possible
    (I think) to create an internal replacement loop that will blow out
    any length if the server has been misconfigured.

 2) Even if it did fix that bug, it does not make the overall server "secure".

The only real solution to (1) is a rewrite of the utility calls such
that they never increase the length of a string without checking the
string's bounds.  As I said earlier, this means fixing in util.c:

     strsubfirst()      -- dest is growing (even with the obfuscated patch)
     http2cgi()         -- w    is growing
     escape_shell_cmd() -- cmd  is growing
     escape_url()       -- url  is growing
     escape_uri()       --         ditto (why are there two identical copies?)
     make_full_path()   -- dst  is growing

The only way to fix these is to change all of their calling routines
(and, in many cases, the parents and grandparents of those routines)
so that they include a MAX length value in the argument list.

That's just util.c (i.e., not including the bugs in translate_name and
unmunge_name).

Normally, I'd put my code where my mouth is (:-) and supply patches for
the appropriate changes.  Unfortunately, I don't have the time right now
and probably won't until September (i.e. forever).  In any case, the 
changes would be so extensive that they would interfere with everyone
else's patches.  However, I do *strongly* encourage someone to take on
this task and make it a high priority -- the server will not be secure
until it is done.  HINT: this would be A GOOD PLACE FOR NCSA to FOCUS
its effort.

.......Roy

Mime
View raw message