On the third line of the CVE’s description of the bug there is a link to the exploit:

BUGTRAQ:20010624 Fw: Bugtraq ID 2503 : Apache Artificially Long Slash Path Directory Listing Exploit

Again, to find it you should browse BUGTRAQ’s archives. In the message, you can read Mark Watchinski’s explanation of the bug at the beginning of his exploit:

http_request.c has a subroutine called ap_sub_req_lookup_file that in ver y specific cases would feed stat() a filename that was longer than stat() coul d handle. This would result in a condition where stat() would return 0 and a directory index would be returned instead of the default index.html .

stat() is a system call used by Apache to check if a file exists. When stat() returns 0, Apache assumes that the file passed as an argument exists. In this case this assumption is wrong: stat() is only returning 0 because it cannot handle the length of the passed argument. For this to work, the modules mod_dir, mod_autoindex, and mod_negotiation have to be loaded (or present) in the main server, and the accessed directory has to have the options Indexes and Multiviews enabled. The exploit creates a request with a $low number of slashes:

$url = "GET ";
$buffer = "/" x $low . " HTTP/1.0rn";
$end = "rnrn";
$url = $url . $buffer . $end;

This piece of code is repeated a number of times, with the variable $low incremented each time. It then sends the request each time:

print $socket "$url";

Finally, it checks the result:

while(<$socket>)
  {
    if($_ =~ "Index of") {

If the result contains “index of,” it means that the targeted server was vulnerable.

NOTE: Your server may use the configuration directives HeaderName and ReadmeName to tailor the server’s output, changing the text “index of,” but nevertheless showing a directory listing because of the vulnerability. So running this against your own server and failing to see “Index of” does not mean you’re not vulnerable; you may have to change the exploit’s code so that it works for your server’s configuration (the exploit will have to look for whatever output is sent by your server for a directory listing, rather than for “Index of”).

Here is a test run of the exploit:

[merc@merc merc]$ ./apache2.pl.txt localhost 80 8092 0
Found the magic number: 4069
Now go do it by hand to see it all
[merc@merc merc]$

If you request a URL like this: http://localhost////////// [... 4069 slashes...] ///, you can get the directory index, and possibly the content of the files in that directory too. Admittedly, typing / 4069 times can be a little tedious, so you could use this instead:

perl -e "print '/' x 4069;"

This short Perl command will print 4069 slashes on screen. You can now use cut-and-paste to copy them into your browser’s address box. Figure 2-2 shows the exploit’s results.

Notice how easy it is to use the exploit even without knowing much about the Web, HTTP, or Apache.

This bug could potentially jeopardize privacy in the server (because an attacker can view any files), as well as security. For instance, an attacker might be able to view your scripts, and therefore know the login and password that the scripts use to connect to the SQL database server.

The solution is simple: Upgrade to a newer version of Apache (at least 1.3.22).

Figure 2-2. The exploit at work

This chapter is from Hardening Apache, by Tony Mobily. (Apress, 2004, ISBN: 1590593782). Check it out at your favorite bookstore today. Buy this book now.