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 minutes
> >work has been turned into real hell (286?).
>
> Ok here's an initial patch, I'm sure someone will come up with something
> 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 they
lose that meaning (on many, although not all, OSes) does not mean it isn'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³ 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 gets
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 any
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