Re: not so false alarm: query cgi problem

[lyonsm () netbistro com (M Lyons)]

On Fri, 10 Jan 1997, Apropos of Nothing wrote:

> For interest sake, Apache defines it's max URL length like this:

> /* The default string lengths */
> #define MAX_STRING_LEN HUGE_STRING_LEN
> #define HUGE_STRING_LEN 8192

> I should note that I haven't gone through the code to find out if the
> server actually truncates the URL; I imagine it does- if it didn't it would
> be susceptable to a fairly easy buffer overflow- but I digress...  I don't
> know how the NCSA server defines string lengths.

NCSA does it exactly the same way.. in fact, that's how the above code came
to be part of Apache, which started life as a mutation of NCSA's httpd. :-)

This issue was actually discussed on the Apache development list just over
a year ago. If you look in read_request_line() in http_protocol.c you'll
see that the HTTP request is truncated to 8192 bytes before it's split
apart into it's components.  The maximum length of the query string is
then 8192 - length of "GET " - length of URI of CGI script.

As it happens, about a year ago it was noticed that there were a couple of
places where multiple HUGE_STRING_LEN size strings were smashed together
into a single HUGE_STRING_LEN buffer with sprintf(), and these were all
immediately hunted down and replaced with pstrcat()'s or the equivalent.

Of course, it's only fluke that this happens to help with the problem
recently discovered in query.c.  There's very little your web server can
realistically do to protect you from buggy CGI scripts, so it's probably
best to start with an empty CGI directory and add only the scripts you
require instead of removing them as you hear about individual security
problems.