Vulnerability in HTTP.sys Could Allow Remote Code Execution | Hacker News Reader

Vulnerability in HTTP.sys Could Allow Remote Code Execution

technet.microsoft.com

101 pointsrunesoerensen37 comments

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?

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

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

It has TransmitFile and TransmitPackets: https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

They were in use (at least TransmitFile was) by IIS long before http.sys was conceived.

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.

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

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

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

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

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

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?

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

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

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

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

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

I'm told it's already done.

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!

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.

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

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

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?

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

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.

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

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

I don't see any details about breaking the stack (just the HTTP stack). Maybe you can request arbitrary ranges of files and they get cached in a way that lets you reference them as ISAPI filters. I'm grasping at straws but I'm not feeling particularly creative right now.

I was also being slightly sarcastic. I'd take the bet this is a memory safety issue, but there's a chance it isn't.

How about that old WMF vulnerability? :)

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.

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.

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

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

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

It's IIS.

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.

This. I can't believe how bad of an idea this was.

...but I just finished updating my servers!

Apparently you didn't.

Reply on news.ycombinator.com