Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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:
  • by Rogerborg (306625) on Friday June 19, 2009 @10:28AM (#28389703) Homepage

    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?

  • Boring (Score:5, Insightful)

    by Anonymous Coward on Friday June 19, 2009 @10:29AM (#28389719)
    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....
  • by Z00L00K (682162) on Friday June 19, 2009 @10:30AM (#28389737) Homepage

    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.

  • by moon3 (1530265) on Friday June 19, 2009 @10:51AM (#28390057)
    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.
  • Re:Why not IIS? (Score:5, Insightful)

    by Malc (1751) on Friday June 19, 2009 @11:08AM (#28390307)

    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.

  • by TheLinuxSRC (683475) * <slashdot.pagewash@com> on Friday June 19, 2009 @11:36AM (#28390681) Homepage
    From the article:

    "...the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated."

    In other words.. the connection is not allowed to "timeout" as there is (bogus) traffic on the connection.
  • by dlgeek (1065796) on Friday June 19, 2009 @11:55AM (#28390921)
    The problem with that is it will break nontrivial uploads using POST since they won't complete in 5 seconds. The real solution is to not count threads or connections below a certain utilization threashold towards the capped max and kill them once you hit real starvation.

In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982