A new Apache DoS vulnerability was reported recently by security researcher Kingcope on the 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 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:
Range: 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,
–CUT–
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 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 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:’https://www.owasp.org/index.php/ModSecurity_CRS_RuleID-%{tx.id}’,tag:’PROTOCOL_VIOLATION/INVALID_HREQ’,tag:’http://www.bad-behavior.ioerror.us/documentation/how-it-works/’,setvar:’tx.msg=%{rule.msg}’,setvar:tx.id=%{rule.id},setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-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.