back to article Tiny-traffic DoS attack spotlights Apache flaw

Security guru Robert "RSnake" Hansen has released a novel DoS attack tool that points to a significant flaw in Apache and other webservers. Hansen calls his creation "Slowloris - the low bandwidth yet greedy and poisonous HTTP client." Unlike an old school Denial of Service attack, which ties up a website by bombarding the …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Happy

    IIS

    "Webservers like IIS uses a "worker pool," allowing as many open connections as its resources will allow."

    But it can't have more 'resources' (aka threads) that a machine of the same spec. So we're talking again 1 to 1, or at max 2 to 1 to defeat them as well.

    Apache simply allows you to configure the number of threads, so if the value is not low enough, there are no problems either. Experienced/savvy admins use stress testing tools before deployment.

    Others get what they deserve.

  2. Tel
    Pirate

    Nasty...

    But... if it's not really going to affect the popular sites out there, then there'd be very little point in hitting the rest: after all, why bother DOSing a web server that hosts sites very few people actually look at anyway?

  3. Kevin McMurtrie Silver badge
    Thumb Down

    Breaking news for the last decade

    As Hansen recently discovered, this is an ancient attack. It was actually a common side effect of buggy dialup modems in the 90s. These modems would switch protocols, re-calibrate, and corrupt data constantly so that the connection degraded to very tiny packets coming in very slowly. It was just fast enough to evade socket timeouts but so slow that the server would eventually become overwhelmed serving many broken modems concurrently.

    Death by slow requests was more troublesome when enterprise servers had 64MB of RAM and no firewall. There are workarounds today.

  4. Ben Schofield
    Thumb Down

    This is news?

    This 'vuln' has been known about for a long, long time. I was of the impression that this was how the vast majority of HTTP DOS based attacks were carried out...? Clearly, I'm in the wrong job and that Captain Obvious cap belongs to me.

  5. Kanhef

    Not really new

    The idea of DOS'ing a server by flooding it with SYN packets and no ACKs has been around for at least a decade. This is essentially the same thing, using HTTP rather than TCP.

  6. tuna 1
    Gates Halo

    Wait, Wait, Wait....What?

    <quote>but his attack doesn't affect IIS6.0, IIS7.0</quote>

    A flaw that doesn't affect MS? The world as I know it is upside-down.

  7. Anonymous Coward
    Paris Hilton

    Forgive my ignorance...

    but doesnt this sound an awful lot like that happened to the shields up guy (google says his name is steve gibson)

    ah RTFA tells me this attack is a http one, not a SYN flood like Gibsons problem was, and "NOT a GET request flooder"

    How many people will not have RTFA?

    either a) everyone is cleverer than me and will not have made that initial mistake,

    or b) fortunately this is the internet and ill bet (1p) at least one person will have done it as well.

    take a cheque?

  8. amanfromMars 1 Silver badge

    Solid Gold or Vapourware.

    "take a cheque?" A bank's guarantee to pay and transfer credit? Why ever not? Are they not Personal Gilts, System Guaranteed?

  9. Anonymous Coward
    Pirate

    It may be old...

    But it still works (well), very often old vulnerabilities do work (like the humble Ping-Of-Death), far too many system admins ignore the older vulnerabilities and concentrate on the latest (arn't we clever) exploits.

  10. Oninoshiko
    Heart

    @ FirstPosting AC

    That would be all fine and good, *IF* the other web servers mentioned used apache's model of dedicating a heavy thread or (worse) process to each connection. I don't know about IIS, but lighttpd does not do this. It uses a light-weight thread to handle multiple connections (easily into the hundreds). An idle thread causes almost NO load on a lighttpd server.

    The only resouce to be worried about on Lighttpd would be file-discriptors, and that likely has gotten better (I last ran it on a 32-bit machine)

    In fairness, I'm told Apache 2 can be configured similerly, but it is not the default, and nowhere near as well documented as it's "prefork-mode"

  11. Nick Kew
    Stop

    Disingenuous

    "Apache did not respond to our request for comment on the bug."

    Did you give us time to respond? The date stamp on your email is just over an hour (72 minutes, to be precise) before that of this article.

    This is not new, and a trawl through Apache mailinglists will find a few mentions of it over the years. For example, the Event MPM effectively nullifies this attack, and was first included in a production release of Apache in 2005.

  12. Frumious Bandersnatch

    asymmetric resource requirements

    Are the hallmark (or even definition) of any DOS attack, no? So this "new-skool" attack isn't really anything of the sort. It is kind of interesting that Apache is vulnerable to this slow starvation attack but I don't see why IIS shouldn't also be vulnerable(*). So long as the web server keeps all valid connections alive, and the client can drag out telling the server what it wants done for long enough, sooner or later it's going to run into some sort of limit on the number of open sockets/running threads, whether that's a limit built into the server or the OS it's running If the server has a high number of these resources, relative to the attacker, then obviously multiple attack machines are needed, but once the tipping point has been reached, it's only a matter of time before the server is starved out.

    (*) At least I can't see anything in the article that says that IIS expires connections in the request phase if they're dawdling too much, which seems to be the obvious defence. AC at 00:56 makes the same point.

  13. F Seiler

    @Tel

    There actually are small companies depending on web presence ;)

    It might not be useful if you're after headlines, but still a mean little trick if your goal is to lock up your competitior's website/shop for some time (or whoeverelse's you might want to damage).

  14. Chronos

    mod_cband

    mod_cband would seem to mitigate this problem for now, using CbandRemoteSpeed to limit simultaneous connections to a reasonable level. Be careful with the setting, especially on web2.0rrhoea sites and do note that mod_cband's restrictions need to be applied to vhosts, not globally.

    Also, the Slowloris code seems to hint at a global Timeout setting <166 seconds being problematic:

    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

    }

    I generally have mine set to 45 and broken modems and slowpokes be damned. The default is assumed to be 300 seconds or five minutes but we wouldn't go shoving an httpd up with the defaults, would we?

  15. A B 3
    IT Angle

    Dear Reg

    I would like to submit a proposal for (2) new icons:

    "Where is the GTA angle?"

    "Where is the sailing angle?"

    GTA seems to the source of all society's ills and so it quite often comes up in articles.

    Sailing angle can refer to a new age of exploration.

  16. bothwell

    A 'fraction'?

    "We're really only talking about a fraction of the Apache sites out there," he says.

    Apache 2x is quite common, no? And the web is mostly comprised of sites that aren't big news and retail sites. Seems like quite a big fraction to me.

    Here's hoping most of the web's sysadmins are using workarounds for it, really.

  17. PhilR
    Thumb Down

    @Nick Kew

    "For example, the Event MPM effectively nullifies this attack, and was first included in a production release of Apache in 2005."

    It may well be included in production releases of Apache, but the documentation for the latest release says:

    "This MPM is experimental, so it may or may not work as expected." (http://httpd.apache.org/docs/2.2/mod/event.html).

  18. frymaster

    Apache trying to spin this a bit, methinks

    They are quite correct that this sort of thing isn't new, but:

    " For example, the Event MPM effectively nullifies this attack, and was first included in a production release of Apache in 2005."

    So I go to the apache website:

    http://httpd.apache.org/docs/2.2/mod/event.html

    "This MPM is experimental, so it may or may not work as expected."

    "Production" and "experimental" are mutually exclusive, no?

  19. Benedict

    blow me

    "epic amounts of traffic"

    epic? EPIC? wtf. Bad register, bad.

  20. Nick Kew
    Stop

    Response from Apache

    Please don't take my comment as an official response from Apache. It was merely intended as a reaction to your publication at 12:15 GMT having emailed an hour earlier.

    I think it's unlikely to represent the whole story, and I've neither done enough testing to give an informed response, nor consulted with my colleagues on the subject. If and when I do, it's unlikely to be in a comment posted on someone else's article!

  21. Anonymous Coward
    Anonymous Coward

    Tarpitting

    Frankly it just sounds like a form of tar pitting to me, and that is neither new or novel.

    So nothing new here at all, there is nothing to see, please move along.

  22. John Smith 19 Gold badge
    Alert

    So this is a generic attack

    IE its a feature of any protocol which has a negotiation type structure.

    From old modem DOS attacks to new HTTP. Same protocol structure -> Same protocol attack.

    So the same countermeasures should be feasible.

    But I doubt these are the only protocols on the Web that work in this fashion.

    Time to check the RFC's

  23. Your alien overlord - fear me
    Heart

    Glad I use IIS

    and the only LInux box I use has lighttpd installed instead of Apache.

  24. SImon Hobson Bronze badge

    To all those "not affected" people ...

    As I read it, IIS and lighthttp ARE vulnerable - but in a different way. OK, they need to hold a connection until it times out or the client closes it, but they don't use huge amounts of resource to do so.

    So you've got oodles of partial requests held, and then suddenly the client completes them all ? This needs very little traffic from the client (MUCH less than opening the original request connection), and suddenly your sever is expected to handle many, many times it's normal peak load.

    I hope these servers have some form of protection against a flood of requests that complete at once - there's a good chance this technique could bypass connection rate limiting if it is applied to connections as they are opened.

  25. This post has been deleted by its author

  26. fajensen
    Flame

    Your message will be ignored

    @AC Monday 22nd June 2009 11:54

    """

    Just because e-mail is a non-interactive communications medium, does not mean you can safely ignore messages until you get around to dealing with them.

    """

    Err, it does mean precisely that. Deal with it!

    The only redeeming feature of email is that one absolutely *can* ignore the mailbox until the appropriate time to deal with the whole lot arrives - instead of being rudely interrupted all the time.

    Those "serious organisations" you like so much will, IMO, be the same ones where you "improve" "the email response time"-KPI by routing all communication through several layers of useless twits causing only the most determined (or desperate) people to actually reach someone that can deal with whatever the problem was!

    PS: I have nothing to do with Apache whatsoever.

  27. Bucky 2
    Thumb Down

    MPM "Solution"

    I'm reading at http://httpd.apache.org/docs/2.2/mod/event.html that:

    "At present, this MPM is incompatible with mod_ssl, and other input filters."

    I'd call that a non-solution if ever I heard one.

  28. Phil Rigby
    Flame

    @AC Monday 22nd June 2009 11:54

    Email is not meant to have instantaneous response. If you can deal with every email that comes in on the second it comes in, good for you. Nik wasn't able to respond to El Reg's email in less than 72 minutes, so what? Doesn't mean he's evil or the product is evil or the company is evil. MS probably would of waited days then sent a generic non-answer.

    Bottom line - email gets answered when I want, if I want. I'm sure other people feel the same way.

    No I don't work for Apache either - I'm an email admin for a large retail chain store.

  29. Jamie Jones Silver badge

    FreeBSD is not affected

    FreeBSD has kernel http_accept filters that hold all requests that aren't completed. This functionality is about 10 years old.

    I tried this program on my modest server, first setting all the timeouts to the default, and the program had no effect.

    Only when I disabled accept filters did the program do as it is suppose to:

    http://www.freebsd.org/cgi/man.cgi?query=accf_http

    http://httpd.apache.org/docs/1.3/mod/core.html#acceptfilter

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

    One in the eye for the Linux fanboys.

  30. Jamie Jones Silver badge

    oh bugger

    please ignore my last message

  31. williamruckman
    Unhappy

    Fix the bug!

    I can see why they don't want Event MPM as an official comment.

    http://httpd.apache.org/docs/2.2/mod/event.html

    Because of:

    "Warning

    This MPM is experimental, so it may or may not work as expected."

    and

    "Issues

    At present, this MPM is incompatible with mod_ssl, and other input filters."

    So, it may nullify the problem, but it doesn't fix it and it is a sloppy piece of crap. They should just do a bug fix on apache instead!!!

  32. Motoma

    The Event MPM is not a solution.

    I know it has already been mentioned that the Event MPM is not a solution because a) it's experimental and b) it doesn't support SSL, but you are forgetting the most important point:

    The Event MPM is just as vulnerable as the Pre-Fork and Worker MPMs.

This topic is closed for new posts.