Mitigating the Apache Range Header DoS Vulnerability

Sunday, August 28, 2011

Mark Baldwin


A new Apache DoS vulnerability was reported recently by security researcher Kingcope on the Full Disclosure mailing list that affects most default installations of Apache 1.3/2.x.  

This report also included a working exploit called that has been shown to reliably exhaust the memory of the web server and cause it to crash.  

RedHat has released an advisory related to this vulnerability.  Currently there is no patch available for this issue.

This exploit generates a very large range header value such as shown below:


bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5- 16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5- 33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5- 50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-66,5- 67,5-68,5-69,5-70,5-71,5-72,5-73,5-74,5-75,5-76,5-77,5-78,5-79,5-80,5-81,5-82,5-83,5- 84,5-85,5-86,5-87,5-88,5-89,5-90,5-91,5-92,5-93,5-94,5-95,5-96,5-97,5-98,5-99,5-100,5- 101,5-102,5-103,5-104,5-105,5-106,5-107,5-108,5-109,5-110,5-111,5-112,5-113,5-114,5- 115,5-116,5-117,5-118,5-119,5-120,5-121,5-122,5-123,5-124,5-125,5-126,5-127,5-128,5- 129,5-130,5-131,5-132,5-133,5-134,5-135,5-136,5-137,5-138,5-139,5-140,5-141,5-142,5- 143,


1268,5-1269,5-1270,5-1271,5-1272,5-1273,5-1274,5-1275,5-1276,5-1277,5-1278,5-1279,5- 1280,5-1281,5-1282,5-1283,5-1284,5-1285,5-1286,5-1287,5-1288,5-1289,5-1290,5-1291,5- 1292,5-1293,5-1294,5-1295,5-1296,5-1297,5-1298,5-1299

Accept-Encoding: gzip

This in turn causes Apache to make separate copies of the requested resource on the server which consumes memory resources, eventually causing the server to start swapping and ultimately to crash.  There is a thread on the GossamerThreads web site that discusses the issue in great depth.

Fortunately, there are some Apache configuration settings that can be adjusted to mitigate this vulnerability:

  • Use mod_headers to completely disallow the use of Range headers.  For example, in your httpd.conf file add the lines:

RequestHeader unset Range 

RequestHeader unset Request-Range

Note that this may impact certain clients, particularly if a web server is used for serving content to e-Readers or providing streaming video. However, this should be safe for most websites that are not serving this type of content.

  • Limit the size of the request field to a only few hundred bytes.  For example, in your httpd.conf file add the line:

LimitRequestFieldSize 200

While this will keep the offending Range header short, it may break other headers such as a large cookie or security fields header settings.  Also, as the attack evolves you may have to further limit this or impose other LimitRequestFields settings.

  • Configure Apache to detect a large number of ranges in the request header and then either ignore the header or reject the request. For example, add the following lines to your httpd.conf file:

SetEnvIf Range (,.*?){5,} bad-range=1 RequestHeader unset Range env=bad-range

The value 5 is arbitrary and may need to be made larger depending on the type of content your site serves. For example, the value may need to be increased to 10 for sites that serve PDFs to eReaders for example, or that serve other types of large files such as video.

  • Finally, if you are using mod_security you can use the below rule to detect and block the attack. Thanks to SpiderLabs for this bit of code.

SecRule REQUEST_HEADERS:Range “^bytes=(\d+)?\-(\d+)?\,\s?(\d+)?\-(\d+)?\,\s?(\d+)?\-(\d+)?\,\s?(\d+)?\-(\d+)?\,\s?(\d+)?\-(\d+)?\,” \ “phase:2,capture,rev:’2.2.1′,t:none,block,msg:’Range: Too many fields’,logdata:’%{matched_var}’severity:’5′,id:’958231′,tag:’RULE_MATURITY/5′,tag:’RULE_ACCURACY/7′,tag:’{}’,tag:’PROTOCOL_VIOLATION/INVALID_HREQ’,tag:’’,setvar:’tx.msg=%{rule.msg}’,{},setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{}-PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}”

I believe that most sites could easily implement the first option (denying Range headers altogether) without any negative impact to site viewers.  

I have tried all of these mitigation strategies on my web server and have not seen any adverse results.  Of course, you should always test these changes in a non-production environment prior to implementing on your production servers.

Cross-posted from

Possibly Related Articles:
Information Security
Denial of Service Apache Attack Vulnerabilities DoS Servers Red Hat
Post Rating I Like this!
Jamie Adams Excellent information. Thank you.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.