Using iRules to mitigate Microsoft's MS15-034 / CVE-2015-1635 Range vulnerability

As more information becomes available regarding the recently published Range vulnerability affecting Microsoft platforms (see MS15-034and CVE-2015-1635), you can start mitigating this issue for your backend applications using the following iRule that would remove the Range header when large ranges are detected.

Additonal mitigations have been published:

Using ASM - https://devcentral.f5.com/s/articles/mitigating-httpsys-remote-code-execution-cve-2015-1635
Using LineRate - https://devcentral.f5.com/s/articles/linerate-range-header-attack-mitigation

Please be sure to test this thoroughly in your production environment.

##############################################

# Name: stop_range_CVE-2015-1635

# Description: This iRule will remove the Range header when detecting large ranges in it.

##############################################

when HTTP_REQUEST {

# remove Range requests for CVE-2015-1635 if the request uses large ranges

if { ([HTTP::header exists "Range"]) and ([HTTP::header "Range"] matches_regex {bytes\s*=.*([0-9]){10,}.*})}

{

HTTP::header remove Range

}

Published Apr 15, 2015

Version 1.0

11 Comments

MW1
Cirrus
Apr 16, 2015
The above would only detect if the range header is an exact match regarding upper and lower case. Should it not be first switching it all to lower ?
Raymond_76056
Nimbostratus
Apr 16, 2015
Http:header is not case sensitive. There is an example script from Hoolio on devcentral
jba3126
Cirrus
Apr 16, 2015
What versions of code supports this iRule? I'm asking because I'm getting the following: Bad Characters. Only the following special characters are allowed: period, asterisk, forward slash, dash, colon, underscore, question mark, equals, at sign, comma, ampersand and space (.*/-:_?=@,& Also @Raymond, can you provide a link to the iRule Hoolio wrote?
Tom_Spector_50
Historic F5 Account
Apr 16, 2015
The iRule is already case insensitive as noted in the HTTP::header syntax page: "The header name is not case sensitive, so for example, 'HTTP::header value HEADER_NAME' will match a header with the name HeAdEr_NaMe."
El-Guapo_29797
Nimbostratus
Apr 16, 2015
Hoolio: what version of F5 does this affect? If using SNAT, the header should not be passed from source to backend server. Thank you.
Nathan_Fowler_1
Nimbostratus
Apr 16, 2015
Interesting
Nathan_Fowler_1
Nimbostratus
Apr 16, 2015
I am unable to post detailed content, however, I propose an alternative iRule which is more strictly fixated on MS15-034, does not false positive, and matches all known evasion techniques for RFC 2616 section 14.35. Please see meow://pastebin.com/BV2uePxk
Nathan_Fowler_1
Nimbostratus
Apr 16, 2015
An updated version of the iRule I've created that more accurately addresses the core vulnerability has been released to address evasion techniques such as "Range: bytes=0-200,201-18446744073709551615" meow://pastebin.com/3MAEE2Fq
IainThomson85_1
Cumulonimbus
Apr 17, 2015
Having read article http://blog.didierstevens.com/2015/04/17/ms15-034-detection-some-observations/ I'm curious to know if the RegEx that has been supplied will mitigate some of the other exploits in the Range field (Counting Whitespaces etc)
Nathan_Fowler_1
Nimbostratus
Apr 17, 2015
I worked with Didier (we're in the same vertical) and the iRule at meow://pastebin.com/3MAEE2Fq will handle those evasions. The RegEx/PCRE supplied in the original iRule on this article will also match, however, the nomenclature isn't quite accurate. While the iRule will match MS15-034 due to the length of the 0xFFF... value in itself it is not precise and will fire on any byte range that is ten digits or more. It's quite aggressive and prone to false positives. The one supplied at meow://pastebin.com/3MAEE2Fq will only match on MS15-034 and has been production tested at $dayjob with the exploit and the evasions identified by Didier.