httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject limits on length of headers
Date Sun, 29 Dec 1996 08:03:46 GMT
Is the limit on the length of the headers read from the client (they
generally appear to be limited to MAX_STRING_LEN, based on a quick glance) 
an intentional design decision to allow other routines to get away without
having to do bounds checking on strings, or is it just a "plenty long
enough for now, if it becomes a problem we fix it" thing?

I am seeing a good number of places (mostly WRT errstr) where you could
run into trouble with possible buffer overflows (and the resulting
possible security holes) if the headers the client sends weren't truncated

Aside from the items which just scrape through without being buffer
overflows because of the limit on the size of headers read, there are
several other places where there are buffer overflow conditions.  It is
trivial to make the server (the child process) get a SIGSEGV because of
them; they may or may not be security risks, depending on a whole lot of
variables.  It is possible that some of them may allow someone to
compromise the account that the web server runs as; a minor problem on
many sites that allow unrestricted CGIs, but still a possible problem in
some situations. 

I'll forward some patches to fix the potential holes that I noticed in a
couple of days once I finish going through the source. 

View raw message