Several detection rules (SNORT, F5, …) are being published these days to detect exploitation of vulnerability MS15-034.
If you are making or modifying such detection rules, I want to share some observations with you.
MS15-034 can be exploited with a GET request with a specially crafted Range header.
Here is the example we’ll use: Range: bytes=2-18446744073709551615
Referring to RFC 2616 section 14.35.1, you can see that this is not the only way to specify a range. Here is the BNF:
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit “=” byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos “-” [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
suffix-byte-range-spec = “-” suffix-length
suffix-length = 1*DIGIT
First of all, whitespace is allowed. So Range: bytes = 2 – 18446744073709551615 is valid (and also caused a BSOD on my test machine).
Second, numbers can have leading zeroes. So Range: bytes=2-018446744073709551615 is valid (and also caused a BSOD on my test machine).
Third, multiple ranges are allowed. So Range: bytes=2-3,4-18446744073709551615 is valid (this did not cause a BSOD on my test machine).
If you are using rules that don’t detect these cases properly, then attackers can easily evade detection. One space character could be all it takes to evade detection. If the rule looks for string “-18446744073709551615”, then using string “- 18446744073709551615” in the attack (extra space character added) will evade detection.
Didier Stevens 
Range: bytes=2-3,4-18446744073709551615 is valid (this did not cause a BSOD on my test machine).
Also note that redundant and overlapping ranges are permitted. Did you try
Range: bytes=2-4,2-18446744073709551615
Comment by Anonymous — Friday 17 April 2015 @ 12:33
[…] header, which extracts portions of webpages from kernel memory and passes them to the client. A specifically crafted range header will trigger the denial-of-service vulnerability so long as certain conditions are met within the […]
Pingback by Active DoS Exploits for MS15-034 Under Way | Threatpost | The first stop for security news — Friday 17 April 2015 @ 15:08
[…] (значение регламентировано RFC 2616, 14.35.1). Ниже приведен пример такого […]
Pingback by Уязвимость CVE-2015-1635 (MS15-034) эксплуатируется in-the-wild | FNIT.RU — Saturday 18 April 2015 @ 10:15
@Anonymous No BSOD.
Comment by Didier Stevens — Saturday 18 April 2015 @ 11:43
[…] could look at using Reverse Proxy rules to block this malformed URL request, but it appears to be pretty complicated. Best to get the patch out as soon as you can. Requires a server […]
Pingback by MS15-034 / KB3042553 IIS Venerability affects Lync Servers: Get Patching Now | Tom Talks UC — Sunday 19 April 2015 @ 9:21
[…] (значение регламентировано RFC 2616, 14.35.1). Ниже приведен пример такого запроса. GET / HTTP/1.1 Host: MS15034 Range: bytes=0-18446744073709551615 […]
Pingback by Уязвимость CVE-2015-1635 (MS15-034) эксплуатируется in-the-wild | Новости — Sunday 19 April 2015 @ 21:18
[…] https://blog.didierstevens.com/2015/04/17/ms15-034-detection-some-observations/ […]
Pingback by MS15-034 Information … | Security Blog — Monday 20 April 2015 @ 8:01
[…] выводу из памяти ядра и передаче на клиент. Если задать специальное значение поля Range, можно активировать DoS-уязвимость при […]
Pingback by Обнаружены активные DoS-эксплойты для MS15-034 | Threatpost | Новости информационной безопасности — Monday 20 April 2015 @ 23:58