On Wed, 14 Jan 1998 janat_private 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 <bsat_private>, > 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 securityat_private will ensure a quick response. -- Marc Slemko | Apache team member marcsat_private | marcat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:39:10 PDT