httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: IBM HTTP SERVER / APACHE (fwd)
Date Sun, 04 Jun 2000 01:45:15 GMT
FYI, FWIW, if I have made any mistakes let me know and I can probably get
them corrected before it makes its way through the moderator.

I would still like to know why the code isn't just checking the stat()
return code, and puking for unexpected (ie. other than "file not found",
etc.) errors.

---------- Forwarded message ----------
Date: Sat, 3 Jun 2000 19:43:33 -0600 (MDT)
From: Marc Slemko <marcs@znep.com>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Re: IBM HTTP SERVER / APACHE

On Wed, 31 May 2000, Marek Roy wrote:

> I haven't seen any advisories for IBM HTTP SERVER running 
> Apache.
> 
> There is a crucial number of "/" (forward slash) you can 
> use to retrieve the contents of the root directory of this 
> particular Web Server.  Using this vulnerability, you can 
> retrieve any files or scripts running from that directory 
> and sub-directories.

First, let me note that I am not very knowledgeable about the Win32
platform and have not investigated this issue in depth.  What is
below is a combination of what I know with what the people who have
looked into the issue more and produced the fix have said.

I'm not exactly sure what you mean by "retrieve any files or scripts".  
Certainly, if you know a URL and it isn't protected then you can access
it.  If that URL is for a CGI, and it isn't protected, you can access that
URL and run the CGI.  You should not, however be relying on people not
being able to guess a URL as a form of security.  In general, URLs are not
treated as confidential information by browsers, proxies, etc.

In any case, back to the issue at hand.

There is a bug in Apache 1.3.x on the Win32 platform.  This does NOT
impact Apache running on Unix.  This is NOT particular to IBM's product,
but is a bug in the Apache HTTP server included in IBM's bundle.  This bug
allows people to get a directory listing of a directory, if it is enabled
in the config, even if an index file is present that would normally be
displayed instead.  While normally this is of little consequence, in some
situations this can be problematic.

Obviously, a temporary workaround is to disable the Indexes option (see
the docs for the "Option" directive for details).

What is happening is that when Apache calls stat() to check if the
index.html (or whatever name it has) exists, Windows will return an error
if the path is too long.  Apache incorrectly treated this as if the file
does not exist.  The included patch has been applied to the Apache CVS
tree and corrects this issue by correcting an existing pathname length
check.

Different numbers of '/'s are required based on the length of the path to
the DocumentRoot.

This is just speculation, but my guess as to why there is an exact number
of '/'s necessary is that if the stat() of ".htaccess" fails in an
unexpected way, then the request will be refused.  "index.html" is only
one character longer, hence the one character window between the stat() of
"index.html" failing and the stat() of ".htaccess" failing.  That is just
speculation, however, I haven't actually looked into it.

There are other places in the code that also call stat() to check for more
important things (eg. .htaccess files), however these do not seem to be
impacted.  On Unix, there are places where the code explicitly checks the
error returned from stat(), and refuses access if it is anything other
than a known "file doesn't exist, really" error.  I have requested that
those familiar with the code look into if something similar is appropriate
here; ie. don't just check if stat() succeeds or fails, but check what the
reason for failing is.

As for the person that mentioned they could crash the server with
particular requests, I have not been able to reproduce that and
have not heard from anyone else who could reproduce it, so there isn't
much I can say about that....

There is a rough plan to release a 1.3.13 version of Apache sometime
this coming week, with various changes including this security fix,
however this is subject to change.  I would presume IBM would
release a fix for their product that integrates that fix, however
that is obviously in their hands and I know no details.

As always, anyone who has found or thinks that they have found a 
security bug in the Apache HTTP server or other Apache Software Foundation
software should get in touch with us at security@apache.org so we can 
investigate and, if necessary, fix the issue.

Thanks.

The patch applied to the Apache CVS tree, as shown at
http://www.apache.org/websrc/cvsweb.cgi/apache-1.3/src/os/win32/util_win32.c.diff?r1=1.33&r2=1.34
follows.

===================================================================
RCS file: /home/cvs/apache-1.3/src/os/win32/util_win32.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- apache-1.3/src/os/win32/util_win32.c	1999/02/18 11:07:14	1.33
+++ apache-1.3/src/os/win32/util_win32.c	2000/06/02 16:30:27	1.34
@@ -580,7 +580,7 @@
     };
 
     /* Test 1 */
-    if (strlen(file) > MAX_PATH) {
+    if (strlen(file) >= MAX_PATH) {
 	/* Path too long for Windows. Note that this test is not valid
 	 * if the path starts with //?/ or \\?\. */
 	return 0;



-- 
     Marc Slemko     | Apache Software Foundation member
     marcs@znep.com  | marc@apache.org



Mime
View raw message