httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@hotwired.com>
Subject limits on length of headers (fwd)
Date Sun, 29 Dec 1996 21:45:13 GMT
It would be really nice if this were included for 1.2 release, whenever
that is.

Dean

---------- Forwarded message ----------
Date: Sun, 29 Dec 1996 01:03:46 -0700 (MST)
From: Marc Slemko <marcs@znep.com>
Reply-To: new-httpd@hyperreal.com
To: new-httpd@hyperreal.com
Subject: limits on length of headers

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
to MAX_STRING_LENGTH chars.  

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. 




Mime
View raw message