Return-Path: owner-bugtraq@SECURITYFOCUS.COM MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sat, 3 Jun 2000 19:43:33 -0600 Reply-To: Marc Slemko Sender: Bugtraq List From: Marc Slemko Subject: Re: IBM HTTP SERVER / APACHE To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <20000531183430.21100.qmail@securityfocus.com> 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