Bug 47417

Summary:	Apache Web Server 2.2.11 Incomplete HTTP Header Resource Exhaustion Vulnerability
Product:	Apache httpd-2	Reporter:	sailesh_kyanam
Component:	Core	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	RESOLVED INVALID
Severity:	major	CC:	a3li
Priority:	P2
Version:	2.2.11
Target Milestone:	---
Hardware:	All
OS:	All
URL:	http://isc.sans.org/diary.html?storyid=6601

Description sailesh_kyanam 2009-06-24 09:30:05 UTC

This alleged vulnerability was reported to us by our internal security group. Apparently, all versions of Apache 2.2, including the latest version 2.2.11 are affected by a bug that can cause DoS attacks to be made very trivially.

While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.

In this case, 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.

This link at iDefense labs has the code required to run teh exploit: https://ialert.idefense.com/idcontent/2009/exploit_code/487469-Web_Server_HTTP_Header_DoS.php.txt

Comment 1 William A. Rowe Jr. 2009-06-24 13:39:38 UTC

This is by design; see LimitRequest* directives for mitigation, especially;

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

The httpd group is reviewing alternatives for timeout processing, but is
already well aware of similar complaints.  In the interim, see iptables and
similar firewall tools and appliances to restrict abusive behavior patterns
at the IP and TCP layers, and LimitRequestFields etc to control the number
of headers expected by your specific environment.

Comment 2 Nick Kew 2009-06-24 17:09:18 UTC

Will, with all due respect, I don't think the fact we're aware of it (and in the wake of slowloris everyone is discussing it) invalidates a bug report applied to current versions.

In the short term, we need to publish something on mitigation.  We have yet to do even that!

Comment 3 William A. Rowe Jr. 2009-06-24 22:20:53 UTC

Nick;

this particular report describes the problem that arbitrary headers of some
arbitrary number (limit 100 by default) are accepted individually by httpd.
That is not a bug.

Reclosing.  An appropriate bug report w.r.t. timeouts would be entirely
appropriate, and I'm sure this reporter would appreciate being cc'ed on that
particular case.

What is described here is absolutely not a bug.

Comment 4 sailesh_kyanam 2009-06-25 21:33:33 UTC

Thanks for your feedback and insights.

Whether we call this a bug, feature or known issue - I was able to very trivially bring down numerous Apache web servers using a modified version of this script. I could "workaround" the issue by reducing timeout to very low numbers (which are always not acceptable in our situation) and/or limit the headers to unreasonably small numbers (no idea what affect this would have on some of our more complex apps). The only realistic option I found to work around this issue is to allocate a large number of processes and assign a large number of threads to each process (I use mpm_worker), and then hope the the script kiddid attacking me is not a persistent *gentleman*.

Ofcourse, there are other options such as using firewalls and IDS - both of which are not practical in many of our use cases.