Slashdot Mirror


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

5 of 203 comments (clear)

  1. Why not IIS? by MBCook · · Score: 3, 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)?

    --
    Comment forecast: Bits of genius surrounded by a sea of mediocrity.
  2. Possible work-around by Norsefire · · Score: 3, Interesting
    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.

  3. Our system may be safe by cjb-nc · · Score: 3, Interesting

    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.

  4. Re:OpenBSD's pf has some mitigation features by raju1kabir · · Score: 3, 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.

    --
    "Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
  5. Re:WTH? This is an absolutely trivial attack by Chris_Jefferson · · Score: 3, 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.

    --
    Combination - fun iPhone puzzling