Attack On a Significant Flaw In Apache Released

Zerimar points out a significant flaw in Apache that can lead to a fairly trivial DoS attack is in the wild. Apache 1.x, 2.x, dhttpd, GoAhead WebServer, and Squid are confirmed vulnerable, while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable. As of this writing, Apache Foundation does not have a patch available. From Rsnake's introduction to the attack tool: "In considering the ramifications of a slow denial of service attack against particular services, rather than flooding networks, a concept emerged that would allow a single machine to take down another machine's web server with minimal bandwidth and side effects on unrelated services and ports. The ideal situation for many denial of service attacks is where all other services remain intact but the webserver itself is completely inaccessible. Slowloris was born from this concept, and is therefore relatively very stealthy compared to most flooding tools."

Comments

So slashdot...

[santax]

be prepared to feel the slashdot-effect yourself for once!

Boring

[Anonymous Coward]

Talk about a boring exploit: no chance for expanding the attack into anything other than a DOS, and if it becomes widespread enough, fairly trivial to fix... (just kill the oldest waiting client that does not have a full header when the last client is taken.) I'd be embarrassed to publish something like this....

Re:Possible work-around

[Bootvis]

The thing that is really amazing about this hack: Human readable perl!

HTTP hints at a solution

[greed]

HTTP 1.1 specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).

What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)

Currently, Apache 2.2 has a single timeout value for all types of requests, but it is interpreted differently for the different types.

If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.

Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.

#!/usr/bin/env perl

use IO::Socket::INET;
use strict;
use constant DEFAULT_PORT => "http";

MAIN: {
if(@ARGV<1 or @ARGV>2) {
die "Usage: $0 host [port]\n";
}
my($host)=shift;
my($port)=@ARGV?shift:DEFAULT_PORT;

my(@sockets);

for(my $cnt=0;$cnt<1000;++$cnt) {
my $socket=new IO::Socket::INET(PeerAddr=>$host,
PeerPort=>$port,
Proto=>"tcp");
unless(defined($socket)) {
die "Cannot create socket to $host:$port--$!\n";
}
$socket->print("\r\n");
push(@sockets,$socket);
print " Have ".@sockets." open.\n";
}
}

Not quite as stealthy, though. At least as above.

Re:HTTP hints at a solution

[greed]

BTW, is there a self-mod value for "I'm not sure I should have posted that"?

Re:Why not IIS?

[Amouth]

unless you are using Session()'s in asp in IIS then one thread in IIS handles multiple connections.

what this is doing is opening a connection (getting a thread to work it) and holding it open (keeping the thread busy) and just keep asking for new ones.

it is very common (always i think) for Apache and allot of web servers to have a max thread's so that the site under heavy traffic doesn't open more connections than it can handle.

where IIS also has a worker thread limit - there is no limit *(you can set one - but not on by default) on how many concurrent connections can be managed by a thread (and new incoming connections are passed to the thread with the lowest current work load - not always the one with less connections)..

if you do what they are doing here i can see IIS behavior would be to slowly pile all these slow - no work connections into one thread and the others would happily go about doing actual work..

where apache would slowly lose access to workable threads as this keeps them busy.

this isn't an exploit on the http or tcp protocol - it is an exploit based on the behavior of the web server based on it's best practices for managing it.

Re:Why not IIS?

[Malc]

Does the HTTP spec say anything about the server application timing out the connection? Seems like reasonable behaviour to me. I would be surprised if this isn't a configurable option in Apache too.

People love to hate it, but IIS has matured in to a very good web server. It's my choice over Apache.

Re:Why not IIS?

[Bemopolis]

Why isn't IIS vulnerable

My guess is that the DoS attack is so slow that, by the time it would have completed, the server has already crashed for a different reason.