Attack On a Significant Flaw In Apache Released 203
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."
Why not IIS? (Score:4, Interesting)
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)?
Possible work-around (Score:4, Interesting)
Lower Apache's timeout to below 166 seconds.
Re:[Sounds Stupid] (Score:3, Interesting)
Re:Why not IIS? (Score:3, Interesting)
Our system may be safe (Score:3, Interesting)
Re:Seems to be a general problem. (Score:3, Interesting)
A connection timeout should be fine. Just start the clock upon accept(). Give the client a generous but limited amount of time to send headers. If the timer expires before the empty line is received, close the connection.
Bonus points for not getting the thread pool involved until the header is complete.
Extra credit for a config option to send a flood of junk to the client and THEN close the socket. That could make attackers considerably more visible to their upstream provider.
Re:Seems to be a general problem. (Score:3, Interesting)
Nothing like replyoing to yourself.
Double extra credit if the junk you send back looks enough like downloading music that the RIAA accidentally joins the forces of good and comes down on the attacker due to ISP snooping but not enough like downloaded music to get you actually busted.
Re:OpenBSD's pf has some mitigation features (Score:4, Interesting)
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:OpenBSD's pf has some mitigation features (Score:1, Interesting)
Since OpenBSD's version of httpd is basically a fork of regular Apache, has anyone tested this against OpenBSD's httpd?
Re:Well its not just Apache (Score:3, Interesting)
Keeping idle sessions open on the server for some period of time is not the flaw. The flaw is that some servers (in default configurations) only handles so many of these idle sessions open before reaching a limit and refusing to accept any new sessions, and that this limit is sufficiently low, and that one client can easily reach this limit.
This particularly affects web servers that fork separate processes to service multiple requests at the same time - and this includes the default configuration of Apache 2 on many systems. (Last I checked, PHP's Apache module implementation only works well with the forking proces model because of thread safety issues.)
IIS does not use this antiquated process model - it's threaded. Apache can be configured to use a threaded model too. Unfortunately, thread-unsafe code is still common.
Re:WTH? This is an absolutely trivial attack (Score:3, Interesting)
Yes, I agree. I've seen a handful of attacks like this over the years. Maybe not exactly this one, but Apache has been vulnerable to this for years and I thought all webservers were. And I thought people just knew about it already. This one is a tough one to fix, its not like Apache can just patch something. It sounds like an architectural change is needed.
Re:So slashdot... (Score:1, Interesting)
A beefy hardware load balancer won't save you from this unless the load balancer is in full HTTP proxy mode (which yours probably is). A different problem that's harder to deal with is slow reads on a dynamic content pages that are not cached (and won't be) and whose size is greater than the LB's 4 or 8K TCP buffer size.
Re:WTH? This is an absolutely trivial attack (Score:3, Interesting)
A simple connlimit declaration in IPTables shuts this down fairly easily...
Will that work for anyone using load balancers (read: people with sites worth hitting)?
Re:Boring (Score:2, Interesting)
No, no they wouldn't.
However like what normally happens whenever some Linux exploit comes out. It's something ridiculously trivial to fix and the windows crowd on slashdot lap it up like it is an "end of the world" scenario. Congratulations on continuing the trend.
Re:WTH? This is an absolutely trivial attack (Score:4, Interesting)
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.