From: Ray Cromwell <rjc@clark.net>
Date: Sat, 7 Oct 95 22:53:45 PDT
To: cypherpunks@toad.com
Subject: Two bugs in CERN3.0 HTTPD
Message-ID: <199510080553.BAA29494@clark.net>
MIME-Version: 1.0
Content-Type: text/plain



I have not verified whether or not both of these are security holes yet, 
but the first one is very probably a security hole.


1) overlong domain bug in Proxy mode
Symptom: send a proxy request to the server, for instance
GET http://overlongdomain HTTP/1.0

  This is the same bug that's in Netscape 1.1. The domain buffer
is a 256 byte buffer declared on the stack. (char host[256])

2) too many headers from CGI script
Symptom: HTScript.c allocates an array of pointers to char on the stack. This
array has size 100. The loop where they parse the output of a CGI script
is not bounds checked.  To crash the server, create a CGI script that
outputs a large number of headers before the document body.
(I simply made a perl script that did for($i=0; $i<1000; $i++) { 
  print "Header$i: $i\n") Although this bug can coredump the process
servicing the request, I doubt it is exploitable. All that happens is 
an unchecked header_line[header_index++]=malloc(some space) gets executed.
In the worst case, you overwrite the stack with excessive malloc pointers.
You may be able to cause a foreign server to crash by having your own fake
server return the exploit, and then getting the foreign server to
read the headers by issuing a proxy request to your server.

Suffice it to say, the CERN code is *littered* with temporary local
stack arrays, and I'm guessing that many of them have faulty bounds
checking (or none at all)

-Ray