Vulnerability in HTTP.sys Could Allow Remote Code Execution

https://technet.microsoft.com/library/security/ms15-034

by runesoerensen • 11 years ago

101 37 11 years ago

technet.microsoft.com

jaytaylor• 11 years ago

What is the actual windows service that is involved/vulnerable?

xfr• 11 years ago

It's IIS.

MichaelGG5• 11 years ago

It says HTTP.SYS. Which is IIS if listening on HTTP, and anything else that uses the HTTP API (like .NET's HttpListener).

It's so awesome when you move HTTP stacks into the kernel, where they rightly belong.

earless1• 11 years ago

So the disclosure mentions that there are no mitigating factors. does this mean that certain versions of windows run Http servers by default that users can't disable?

That's pretty scary

MichaelGG5• 11 years ago

I don't know if HTTP.SYS is included in every install, but you do not need to be running MS's webserver to use it. Instead of letting apps bind to port 80/443/whatever and doing HTTP themselves, MS encourages using their special interface to make the kernel listen for you. So yes, people might be accidentally running this.

Does Remote PowerShell bind to HTTP.SYS or do its own thing?

jj10• 11 years ago

WinRM (AKA PowerShell Remoting) uses HTTP.sys and is on by default on server SKUs.

Jayku1• 11 years ago

WinRM and PowerShell Remoting do not use Kernel Mode Caching, and are therefore not vulnerable.

userbinator• 11 years ago

this mean that certain versions of windows run Http servers by default that users can't disable

Apparently yes; this is on Windows 7 and above:

http://www.mikeplate.com/2011/11/06/stop-http-sys-from-liste...

So those on Vista or below aren't affected unless they explicitly running IIS or something else that's using HTTP.sys; and I can confirm that nothing is listening on port 80 on my XP box (nor is HTTP.sys loaded.)

est• 11 years ago

If you have Windows Media Player then you have DLNA and everything and there you have to use HTTP.sys to listen on a http port.

That's called Home Sharing IIRC

simplexion• 11 years ago

...but I just finished updating my servers!

krapp• 11 years ago

Apparently you didn't.

nbevans2• 11 years ago

It's a bad time for the C programming language. First OpenSSL. Then SQLite this week. Now HTTP.sys. They didn't move HTTP into the kernel as a driver lightly; it was done on the assumption the code would be vetted and tested throughly. Clearly that has failed.

MichaelGG5• 11 years ago

Not so fast. We don't know if this is actually a memory safety issue. It be some sort of non-memory logic error.

UnoriginalGuy• 11 years ago

A non-memory logic error that allows remote code execution by breaking the stack? Can you give an example? Most of the examples I can think of are either directly or indirectly a problem of memory safety (for execution remote code rather than simply crashing (like a stack overflow)).

higherpurpose• 11 years ago

By OpenSSL are you referring to HeartBleed? Windows has already had a similarly serious (let's call it) "bug" that allowed remote execution in IIS servers. Except unlike Heartbleed which only existed for 2 years, Microsoft's bug was in Windows for 20 years.

But since Microsoft (on purpose) didn't make a unique name and logo for it, the media didn't pick it up. They gave it an obscure name and made it part of a larger Windows update, where they also added a few other "security improvements", which the media actually reported on more than on the bug.

Some were calling it "WinShock" if you want to Google (or Bing) for it.

gtirloni2• 11 years ago

Interesting that if you don't make a show out of a bug, you're doing it "on purpose". I assume you didn't mean to generalize but the current practice of naming bugs, making logos and what not is just silly.

nbevans2• 11 years ago

"But since Microsoft (on purpose) didn't make a unique name and logo for it, the media didn't pick it up."

Haha! I don't think MS got that memo about having to name bugs and make logos.

tdicola• 11 years ago

Ouch, hopefully doesn't turn into blaster 2.0. These days you're just asking for trouble if port 80 is open and you don't have a need for it, though.

gtirloni2• 11 years ago

Couldn't parse the vulnerability name. Do you have a CVE number where I can find technical details about that?

mukyu• 11 years ago

Blaster[0] was a worm. It used CVE-2003-0352.[1]

[0] http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0352

blinkingled2• 11 years ago

It's 2015 and Microsoft still has a kernel space HTTP component, thus needing to run some part of the web server code paths in SYSTEM user's context!

I am curious as to what the reasons are - what are the benefits of this that outweigh the huge risk (as demonstrated repeatedly by the various vulnerabilities) of running in HTTP code in the kernel? Only thing I can think of is they are trying to squeeze the last bit of performance / scalability but surely that could only mean that there are parts of the kernel (ctx switching overhead, threading scalability, page cache performance, etc.) that need to be fixed in order to not need these type of hacks in 2015?

ComputerGuru2• 11 years ago

It's actually not "still has" - this was a major feature that brought significant performance improvements and something they pushed hard for: http://www.microsoft.com/technet/prodtechnol/WindowsServer20...

(Not saying I agree or disagree, just saying that this isn't so much an ancient artifact as it is a fairly recent and purposeful addition.)

blinkingled2• 11 years ago

• Kernel-mode caching. Requests for cached responses are served without switching to user mode.

-- NT is missing sendfile()? Also syscalls are fast on x86_64, most stuff is dynamic now a days and serving static files straight from page cache is fast enough.

• Kernel-mode request queuing. Requests cause less overhead in context switching

-- This one is somewhat valid but given you can ctx switch pretty fast on modern CPUs it is not clear how big the gains are.

Yeah but there would be some gains - that's not deniable. Question is whether they are big enough to risk something like the vulnerability at hand.

kogir• 11 years ago

I imagine the thinking was similar to that behind FreeBSD's accf_http kernel module? https://www.freebsd.org/cgi/man.cgi?accf_http

HTTP.sys obviously does a lot more, but especially back in the Windows 2000 days, the performance difference was substantial.

justincormack• 11 years ago

Linux used to have in kernel httpd too, called tux[1].

[1] https://en.wikipedia.org/wiki/TUX_web_server

jbrantly2• 11 years ago

Does anyone know if they're planning to hotfix Azure PaaS servers? They just pushed a new update on April 2nd [1] but that did not include MS15-034 [2]. I really hope they don't plan on waiting a few weeks before pushing this out.

1. http://azure.microsoft.com/en-us/documentation/articles/clou... 2. http://azure.microsoft.com/en-us/documentation/articles/clou...

shanselman• 11 years ago

I'm told it's already done.

jbrantly2• 11 years ago

It would seem you're right. I can't find a way to confirm what Guest OS version I'm on (WA-GUEST-OS-*) but running Get-AzureOSVersion has newer versions than what's shown on the site and checking installed updates on the server shows that this has been patched. That is exactly what I wanted to see, thanks!

ComputerGuru2• 11 years ago

The details of CVE-2015-1635 seem to still be undisclosed, but given that it's an HTTP praying issue I wonder if running IIS behind nginx or another reverse proxy (a very common configuration) would help any? It's not listed under mitigating factors, but maybe that's really less of a mitigating factor and more of a "doesn't apply" situation?

MichaelGG5• 11 years ago

It might be. Depends on how well nginx or another frontend will sanitize or parse things. Another link says it's a range header issue. So if nginx doesn't handle line folding, but HTTP.SYS does, you might still sneak it by. HTTP is a clusterfuck to parse.

Anyways I doubt MS would write "Mitigating factor: Not using IIS."

Also note, this does not just apply to IIS. It applies to the Windows kernel HTTP stack (?!), HTTP.SYS. Which is used by many things apart from IIS. And can even be listening when your app is not running (OS opens a socket on port 80, 443, whatever, runs it as SYSTEM (PID 4), then passes the HTTP messages off to your app if your app is up and connected.)

_aqr_• 11 years ago

I can't find much public information about this vulnerability other than the Snort guys indicating this is a range header integer overflow attempt [1].

Anybody else have anything to share?

[1] https://www.snort.org/advisories/vrt-rules-2015-04-14

adsche• 11 years ago

Seems to be this: https://twitter.com/NexusFandom/status/588254994203303937/ph...

rsalt• 11 years ago

Do we know exactly what kind of packets lead to such remote code execution ?

Vulnerability in HTTP.sys Could Allow Remote Code Execution

Related Stories