Forgot your password?
typodupeerror
Security The Internet

Attack On a Significant Flaw In Apache Released 203

Posted by kdawson
from the take-it-slow dept.
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."
This discussion has been archived. No new comments can be posted.

Attack On a Significant Flaw In Apache Released

Comments Filter:
  • Why not IIS? (Score:4, Interesting)

    by MBCook (132727) <foobarsoft@foobarsoft.com> on Friday June 19, 2009 @10:29AM (#28389711) Homepage

    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)

    by Norsefire (1494323) * on Friday June 19, 2009 @10:35AM (#28389809) Journal
    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:[Sounds Stupid] (Score:3, Interesting)

    by segedunum (883035) on Friday June 19, 2009 @10:39AM (#28389885)
    Having read this more this just strikes me as incredibly stupid. Did they publish this? Surely we're just talking about a timeout implementation here where the web server will say "Ahhhh, well you didn't complete that header, bye, bye"?
  • Re:Why not IIS? (Score:3, Interesting)

    by nicolas.kassis (875270) on Friday June 19, 2009 @10:43AM (#28389929)
    What I'm thinking, is this basically another time where those not vulnerable were actually not respecting the spec?
  • by cjb-nc (887319) on Friday June 19, 2009 @10:47AM (#28389991)
    Obviously need to verify this, but we already run mod_cband [sourceforge.net] 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.
  • by sjames (1099) on Friday June 19, 2009 @10:51AM (#28390043) Homepage

    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.

  • by sjames (1099) on Friday June 19, 2009 @10:57AM (#28390125) Homepage

    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.

  • by raju1kabir (251972) on Friday June 19, 2009 @11:02AM (#28390201) Homepage

    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.

  • by Anonymous Coward on Friday June 19, 2009 @11:11AM (#28390337)

    Since OpenBSD's version of httpd is basically a fork of regular Apache, has anyone tested this against OpenBSD's httpd?

  • by nxtw (866177) on Friday June 19, 2009 @11:53AM (#28390881)

    Just tested on www.microsoft.com and I sat there in the header negotiating part for over 3 minutes before the pipe broke on remote end (I didn't do anything.) Slight change in that slowloris makes IIS* vulnerable too.

    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.

  • by suso (153703) * on Friday June 19, 2009 @12:20PM (#28391283) Homepage Journal

    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)

    by Anonymous Coward on Friday June 19, 2009 @12:45PM (#28391613)

    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.

  • by ToasterMonkey (467067) on Friday June 19, 2009 @12:49PM (#28391691) Homepage

    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)

    by LingNoi (1066278) on Friday June 19, 2009 @01:18PM (#28392065)

    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.

  • by Chris_Jefferson (581445) on Friday June 19, 2009 @01:50PM (#28392523) Homepage

    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.

The first version always gets thrown away.

Working...