More info after the jump. SANS Diary on the Exploit

…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.
The initial part of the HTTP request is completely legitimate:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:

X-a: b\r\n

Which obviously doesn’t mean anything to the server so it keeps waiting for the rest of the header to arrive

Essentially the attacker sends a partial legitimate browser UA string, albeit incomplete with intentions to send the rest of the data to complete the string, yet never does. This in turn holds the session open on the server end, quickly maxing the server’s connection table waiting for “clients” to complete the request.

This attack requires a very small amount of bandwidth to bring a server to its knees. There is no known workaround or patch yet, but can be stopped by including the signature for this type of attack in your IDS (if you have one in front of the web server.)

I recall Check Point VPN-1 R65 introducing a DoS protection technique that could possibly reduce the impact of such type of DoS attack. To keep the firewall’s connections table from becoming saturated in the event of a Denial-of-Service attack, a three-way session verification would take place. When a connection request it is initiated, the firewall would send back an acknowledgment to go ahead and start sending traffic (if the specific connection was allowed in the rulebase), but only keep the connection record in memory, not committing it to the actual connections table on the firewall. If no traffic was returned by the requestor, then the connection would be ignored and purged from memory. This kept the connections table clean of any “dummy” connections and thus would not become saturated and cause traffic-flow to come to a grinding halt. Maybe the fix could be to do something on an HTTP session scale with Apache.