MS15-034

We came up with this, be good to get some public opinion.

when HTTP_REQUEST { if { [HTTP::header "range"] contains "0-18446744073709551615" } { drop } }

i'm not 100% that that value will always be that value any number greater than 18446744073709551614 would trigger an overflow

What happens if you just strip the range header in the http profile? If I'm reading the RFC correctly, servers don't have to implement it or respect it. Maybe a quick fix for the time being? It certainly could break things....ymmv.

HEADER SANITIZATION First, you can modify the HTTP profile to simply remove the Range header. HTTP header removal – and replacement – is a common means of manipulating request and response headers as a means to “fix” broken applications, clients, or enable other functionality. This is a form of header sanitization, used typically to remove non-compliant header values that may or may not be malicious, but are undesirable. The Apache suggestion is to remove any Range header with 5 or more values.

Note that this could itself break clients whose functionality expects a specific data set as specified by the RANGE header. As it is a rarely used header it is unlikely to impact clients adversely, but caution is always advised. Collaborate with developers and understand the implications before arbitrarily removing HTTP headers that may be necessary to application functionality.

After testing we actually found you need to block on the container of "18446744073709551615" - if you have anything in front of it it will drop the connection, but still allow remote code exec/BSOD.

This is a modified version of what Chris H listed -> when HTTP_REQUEST { set vip [IP::local_addr]:[TCP::local_port] if { [HTTP::header "range"] contains "18446744073709551615" } { log local0. "Attempted MS15-034 Exploitation Attempt to [HTTP::host] in URI [HTTP::uri] from [IP::client_addr] on VIP $vip" drop } }

With this, we found that it prevented the remote code exec/BSOD, We also found if you change the 18446744073709551615 to anything else it would not cause the bug, also if you increment the 0 to say, 1 and then down the 18446744073709551615 to 18446744073709551614 it would also not cause the bug to trip. I'm sure there will be more about this over the days to come.

At this point the above iRule is what worked in our lab testing, hope it helps.

Hello,

The below is a recent article on this issue. It does not drop the request, it removes the Range header.

https://devcentral.f5.com/articles/using-irules-to-mitigate-microsofts-ms15-034-cve-2015-1635-range-vulnerability

 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
}
}