> 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
>> 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