> 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