Bugtraq mailing list archives
Re: DoS attack: apache (& other) .htaccess Authentication
From: marcs () ZNEP COM (Marc Slemko)
Date: Thu, 15 Jan 1998 00:54:33 -0700
On Wed, 14 Jan 1998 jan () WEDEKIND DE wrote:
Sorry, if already known (not found anywhere or even heared about): At the beginning of the week (after the release of apache 1.2.5) we discoverd a DoS attack in apache and (eventually) other / all (?) httpd's. Many thanks to Bernard "sendmail" Steiner <bs () de uu net>, who got the important idea. For apache 1.2.x (and very sure all versions before), the DoS may be exploited if both of the following conditions are true: - the intruder has (at least FTP) write access to (at least) one HTML directory - per directory access (AccessFileName configuration directive) is enabled and the filename is known to the intruder (default is .htaccess)
Yes. There are also numerous other files that can do this, and numerous other methods that users with access to the web server can do things such as this. We are looking at the overall design to see if there are ways we can improve on such things in general. [...]
If you're now trying to open this directory (or any file within) and enter any user / password combination, you'll get a hanging (death running) client. This is, because it's reading /dev/zero and searches for a colon (':') to separate the user name from the password field (mod_auth.c, get_pw(), line 127). Now the intruder may stop this request in the browser (the server client process will still continue) and start a new one. The next client will be forced to read /dev/zero. Repeat this, until 'MaxClient' will be reached. Not only this server will stop to work (e.g. the parent will wait for all further requests for any of it's child), but also the machine will going almost to hang with a CPU load of about MaxClient. possible fixes: a) workaround Disable .htaccess in srm.conf by commenting out AccessFileName: (default is NULL in the apache distribution, e.g. disabled) #AccessFileName .htaccess b) patch to apache source Because also other authentication methods may be exploitable I would prefer to patch it in a way that it's no longer be available to open /dev/zero (or any other device) for reading, so I patched fpopen() in alloc.c:
The difficulty with this is that it causes excessive stat()s, especially on servers where people don't disable htaccess searching outside of their document tree. You also end up with repeated stat()s in places. We are looking at a solution to avoid some of these issues. Files served by Apache to the client are already checked for such things, however they are stat()ed anyway so the performance impact is minimal. As always, we welcome suggestions, ideas, and details of problems. Some suggestions are simply not really possible to implement sanely because of the lack of good facilities within Unix to oversee things such as this. rlimit()s by themself aren't really enough and cause great problems in that you can't generally recover from them to do anything useful. Limiting the size of memory pools is one possibility for dealing with memory consumption; that is a reasonably easy change. The ability to limit the number of connections from any single host would be useful, but things like proxys can cause problems. CPU-based attacks are more difficult to solve. Just to be sure that all readers are aware of this, the recent number of postings about possible denial of service attacks against Apache may make it appear that Apache is poorly written and very bad compared to other servers. There are things that can be improved and code that is written poorly, and I am not attempting to make excuses for Apache. However, many, if not most, other servers of many types have similar flaws. A few have very successfully implemented protection against denial of service attacks of most forms, however most of their methods can not be applied to web servers very effectively. Most servers on the Internet can be successfully targetted by a denial of service attack; many of them don't have pretty exploit scripts and may not be published, but they exist and a determined and cluefull attacker has many attacks to choose from. This is something that needs work in general in a lot of software and protocols, including Apache. As a reminder, sending suspected security holes to security () apache org will ensure a quick response. -- Marc Slemko | Apache team member marcs () znep com | marc () apache org
Current thread:
- Correction: CPSN 9:971208: Solaris /var Permission Problems MATTHEW POTTER (Jan 13)
- Xserver stack smashed Pavel Kankovsky (Jan 13)
- Re: Xserver stack smashed M Shariful Anam (Jan 14)
- DoS attack: apache (& other) .htaccess Authentication jan () WEDEKIND DE (Jan 14)
- Re: DoS attack: apache (& other) .htaccess Authentication Marc Slemko (Jan 14)
- Re: DoS attack: apache (& other) .htaccess Authentication Tim Newsham (Jan 15)
- Re: DoS attack: apache (& other) .htaccess Authentication Dustin Sallings (Jan 15)
- Re: DoS attack: apache (& other) .htaccess Authentication Casper Dik (Jan 16)
- pbomb'ing SSH on a FreeBSD box. Jeff Johnson (Jan 15)
- Re: pbomb'ing SSH on a FreeBSD box. FrontLine Assembly (Jan 17)
- Re: DoS attack: apache (& other) .htaccess Authentication Dean Gaudet (Jan 16)
- Re: GCC 2.7.? /tmp files dichro-bugtraq () RCPT TO (Jan 17)
- Re: GCC 2.7.? /tmp files Zack Weinberg (Jan 18)
- Re: GCC 2.7.? /tmp files John Gotts (Jan 19)
- CERT Vendor-Initiated Bulletin VB-98.01 - excite Aleph One (Jan 19)
- Xserver stack smashed Pavel Kankovsky (Jan 13)