Date: Tue, 18 Apr 1995 22:57:31 -0500 From: wam@cs.purdue.edu (William McVey) To: jfieber@cs.smith.edu (John Fieber) Cc: nc@ain.charm.net (Network Coordinator), freebsd-security@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: httpd - security problem? (question, not a statement) Message-ID: <199504190357.WAA09930@moriarty.cs.purdue.edu>
next in thread | raw e-mail | index | archive | help
John Fieber wrote:
>There was a bug in the NCSA http server which has since been
>fixed. I'm not currently aware of any problems with the CERN
>server.
Actually, the one "hole" that an exploit script was written for (and
published) was fixed. The NCSA http server still has lots of sloppy
code that are indicate security problems. (ie, lots of strcpy as
opposed to strncpy, sprintf's into fixed buffers with no range
checking, etc.) I've appended a copy of a mail message posted to
bugtraq that details just one of the other vulnerabilities. There are
others, I'm sure.
-- William McVey
System Support Staff
Computer Science Department
Purdue University
----- Begin included message (copied without permission) -----
From: Paul Phillips <paulp@CERF.NET>
Date: Tue, 11 Apr 1995 20:59:05 -0700
Message-Id: <199504120359.UAA03182@nic.cerf.net>
Newsgroups: comp.infosystems.www.providers,comp.security.unix
Subject: Still security holes in NCSA httpd 1.3R
Keywords: security httpd www
Cc: bugtraq@fc.net, www-security@ns1.rutgers.edu
Precedence: bulk
NCSA has been claiming at <URL:http://hoohoo.ncsa.uiuc.edu>; that their
patch to httpd, which fixed the hole in strsubfirst, was sufficient
to fix the stack overflow bug discovered by Thomas Lopatic. This is
incorrect. There is at least one more instance of the same problem,
this one in log_reason. NCSA has provided a performance reason not to
#define MAX_STRING_LEN to HUGE_STRING_LEN (i.e. you will enter swap
hell) and they are correct about that, but unfortunately that doesn't
magically make the hole go away.
>>> begin code traversal >>>
When accept is handed some data, httpd.c calls process_request in
http_request.c:
213: process_request(0,stdout);
process_request allocates url[HUGE_STRING_LEN] for parsing out
the URL. It calls getline in util.c to obtain the info from the
socket:
104: if(getline(l,HUGE_STRING_LEN,in,timeout))
process_request now decides what the method is, and calls the
relevant function. Take GET for example: it calls process_get
in http_get.c with the url as an argument:
143: process_get(in,out,m,url,args);
Let's say it's a standard document, so process_get calls send_node
with the url as an argument (still possibly HUGE_STRING_LEN long)
195: send_node(url,args,in,out);
Now send_node does various checks. Let's say the file does not
exist: send_node wants to log it, here:
122: log_reason("file does not exist",file);
where file is the passed url, still possible 8192 characters.
log_reason is in http_log.c, and quite short:
void log_reason(char *reason, char *file) {
char t[MAX_STRING_LEN];
sprintf(t,"httpd: access to %s failed for %s, reason: %s",
file,remote_name,reason);
log_error(t);
}
The file can be 8192 characters, but it's sprintfed into a 256
character buffer.
>>> end code traversal >>>
This particular traversal is just an example, log_reason is called
from several places with overlarge buffers.
I pointed this out to the httpd people at NCSA, who promised a
patch but haven't acted with much alacrity. Frankly I am very
skeptical that any patch will fix all holes until I finish checking
out all the code. When 1.4 is released to the public I will
examine it in depth as soon as possible.
Regards,
--
Paul Phillips
paulp@cerf.net
----- Begin included message -----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504190357.WAA09930>