Subject: Re: Possible security problem in referer_log_transaction... ? (fwd)
To: new-httpd@hyperreal.com
Date: Mon, 18 Dec 1995 20:50:24 +0000 (GMT)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
In-Reply-To: <Pine.BSI.3.91.951218121806.6445J-100000@taz.hyperreal.com> from
 "Brian Behlendorf" at Dec 18, 95 12:18:19 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3529      
Message-ID: <9512182050.aa05074@gonzo.ben.algroup.co.uk>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

> 
> 
> ---------- Forwarded message ----------
> Date: Sat, 16 Dec 1995 22:14:48 -0801 (PST)
> From: Mike A Lyons <lyonsm@synaptic.net>
> To: new-httpd@hyperreal.com
> Subject: Possible security problem in referer_log_transaction... ?
> 
> 
> Hello.  Sorry to bother everyone.. I'm painfully inexperienced at this
> sort of thing, but this looked important enough that I'm willing to accept
> the requisite flames and humiliation if this turns out to be a flawed
> observation.  Please, show me no mercy if this proves to be the case. 
> 
> 
> In the function referer_log_transaction() in mod_log_referer.c as included
> in the 1.0.0 release (but, perhaps fortuitously, not enabled by default),
> the following line produces the log file output (line 200): 
> 
>           sprintf(str, "%s -> %s\n", referer,
>                   r->uri);
> 
> str is a local string of length HUGE_STRING_LEN (defined to be 8k in
> httpd.h, and is also the same length as MAX_STRING_LEN, presumably so that
> any security problems in any imported ncsa code will go away).  (These
> seem like awfully big strings to be slinging around the stack, but I'm
> sure that's already been discussed on this list and it isn't the point
> anyway). 
> 
> referer is a straightforward char* to the Referer header retrieved from
> table_get() earlier in the function.  Tracing through (phew!) the code
> that appears to be responsible for setting it up in http_protocol.c it
> appears to have a maximum size of MAX_STRING_LEN - length of "Referer: " -
> 2 (CR/LF).  This value, naturally, comes from the client originally.
> 
> r->uri is, of course, the URI portion of the client's request, after
> having the query string, if any, shaved off in parse_uri().  It appears to
> have a maximum size of HUGE_STRING_LEN - length of "GET " - length of
> "HTTP/1.0" - (length of query string, if any) - (2 for CR/LF).  Naturally,
> this value too comes from the client. 
> 
> Unless I've missed something stupid (which is distinctly possible: the
> "simple" task of tracing the origins of these two variables has ended up
> taking me all afternoon and evening, and involved ranging through what
> felt like 40% of the utility functions [Apache has got a lot of nifty
> utility routines, btw!] to be sure they weren't truncating anything), up
> to 16359 bytes of untrusted information are being passed into a sprintf to
> a buffer on the stack that can only hold 8192 bytes (well, minus the 
> " -> " inserted between the two items, and the '\n' at the end of the 
> string). 
> 
> If this is true, it's similar to the syslogd bug discovered earlier this
> year, and an exploit client may be feasible.  This would also imply that
> adoption of the seteuid() patch should be delayed until at least a few of
> the other possibly insecure sprintf()'s that a grep of the source tree
> turned up are examined (hopefully by someone more sure of themselves than
> me). 
> 
> 
> Now, please tell me I'm wrong, and don't worry about doing so gently.  If
> this has been a complete waste of your time I deserve whatever I get. :-)
> 
> Regards, Mike.

Well, yes, I fear the man is right. We should probably ban all use of functions
which don't check length. This is likely to be quite a hard task, but vital for
security.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.