[5891] in bugtraq
Re: Apache DoS attack?
daemon@ATHENA.MIT.EDU (Marc Slemko)
Tue Dec 30 15:24:56 1997
Date: Tue, 30 Dec 1997 12:47:26 -0700
Reply-To: Marc Slemko <marcs@znep.com>
From: Marc Slemko <marcs@ZNEP.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <01bd1540$d79ca720$LocalHost@LCAMTUF>
Some of the below issues have been addressed partly in other posts, but=
I
want to clarify them. Due to list lag, we may have some things crossin=
g
in the mail.
On Tue, 30 Dec 1997, Mark Lowes wrote:
> On Tue, 30 Dec 1997 11:07:04 +0100, you wrote:
>
> >[execuse me if it has been discovered before]
>
> First I've heard.
>
> >Here's a simple exploit for Apache httpd version 1.2.x (tested on 1.=
2.4).
> >When launched, causes incerases of victim's load average and extreme
> >slowdowns of disk operations. On my i586 Linux annoying slowdown has=
been
> >experienced immediately (after maybe 5 seconds). After about 4 minut=
es
> >work has been turned into real hell (286?).
>
> Ok here's an initial patch, I'm sure someone will come up with someth=
ing
> better and more effcient but it works. :)
It is not, in general, a valid solution. Multiple '/'s can and do have
meaning in HTTP requests. Just because when mapped to a filesystem the=
y
lose that meaning (on many, although not all, OSes) does not mean it is=
n't
there. Parts of a URI that do map to the filesystem directly can either
have multiple '/'s rejected or collapsed. Other parts must not be
tampered with.
On Tue, 30 Dec 1997, Micha=B3 Zalewski wrote:
> Apache patch by Mark Lowes:
>
> [...]
> + /* Compress multiple '/' characters into one */
> + /* To prevent "GET //////..." attack */
> [...]
>
> After a few tests I discovered that Apache first looks for files
> [index|homepage].[html|shtml|cgi] (probably it makes over 32000
> chdirs :), then dies, throwing 'filename too long' error into logs.
> Client gets 'Forbidden' response and disconnects. But httpd child
> process still stays in background, wasting large amount of CPU time
> and system resources. Note it happends _only_ after this error,
> so '//...' sequence must as long as it's possible (about 7 kB).
> The PERFECT httpd patch should also fix httpd's cleanup, to make
> httpd a little more stable :)
I can find nothing to support the above suggestion. You are seeing two
different problems. First, you are generating a filename too long for
your OS. That is what causes the logged error messages once Apache get=
s
around to trying to serve the request. Second, you are running into an
inefficient O(n^2) implementation of no2slash() in Apache that makes it
take a long time to get around to handling the request. I can find
nothing else going on, and simply fixing up no2slash() eliminates the
problem as far as I can see.
Please see the patch Dean Gaudet has posted to bugtraq for the solution=
.
It would be appreciated if people would contact someone from the Apache
Group regarding such things before posting to bugtraq; that goes for an=
y
issue with any program. It simply avoids the whole round of wild
speculation before a proper patch is released and I think you will find=
we
are quite responsive.
--
Marc Slemko | Apache team member
marcs@znep.com | marc@apache.org
