NCSA httpd Patch for Buffer Overflow

A vulnerablity was recently (2/17/95) discovered in the NCSA httpd Release 1.3. A program which will break into an HP system running the precompiled httpd has been published, along with step by step instructions. The program overflows a buffer into program space which then gets executed.

If you are running a precompiled NCSA httpd, please ftp a new copy of the binary. If you have compiled your own source code, we recommend applying the following Patch to fix the vulnerability in the NCSA HTTP Daemon V.1.3 for UNIX. It modifies the strsubfirst subroutine in util.c.

We believe that earlier versions of the server are vulnerable to a similar attack, and strsubfirst should be modified for all releases of the server.

Cert Advisory CA-95:04 describes the problem and includes two suggested steps. We do not recommend taking step 1, which increases MAX_STRING_LEN to 8192. There are 154 occurences of variables using MAX_STRING_LEN and changing them from 256 to 8192 bytes is going to expand the memory needed to run httpd tremendously! On top of that, httpd forks a new process (a complete copy of the parent) for each connection, which if your site gets hit a lot will use unnecessarily large amounts of memory. We have already had reports from admins who have made the change saying they are experiencing performance degradation due to swapping. Step 2, applying the patch to util.c, should be sufficient to fix the problem. There is significantly less forking in Release 1.4 of the NCSA HTTP Daemon which will be released soon.

Detecting a Break-in

If the access log contains control characters, there is a chance that someone has tried to break into your system. If your server has died recently, they failed at least one attempt. And, if your server has not crashed and there are control characters in the access log you should assume your system has been compromised.

In this case, servers which currently use the User Directive to run the server as "nobody", have limited the potential damage of an intruder to those commands which "nobody" may execute.

Control Characters in the Access Log

You've discovered control characters in your access log. How do you tell if was an intruder?

If the beginning of the line containing the control characters begins sensibly (eg. machine name, and date (the GET periodically gets clobbered)) and ends with a series of control characters, it is a break-in attempt. If the beginning of the line starts with control characters (often nulls), this is a symptom of a collision problem that occurs when two childern try to write to the access log simultaneously. This problem has only been seen with moderately to heavily loaded servers. (We are working to fix this in Release 1.4.)

Other ways to Make Your Server More Secure

A tutorial about running a secure server is available. We also recommend that the User Directive be used to run the server as "nobody".

Patched Source and Binaries

The patched source and precompiled binaries are available. We will also be correcting the source for previous releases, but we will NOT be generating binaries for previous releases.

Elizabeth Frank

efrank@ncsa.uiuc.edu