Remote Code Execution Vulnerability Found In Windows HTTP Stack

jones_supa writes: A remote code execution vulnerability exists in the Windows HTTP stack that is caused when HTTP.SYS parses specially-crafted HTTP requests. An attacker who has successfully exploited this vulnerability could execute arbitrary code under the SYSTEM context. Details of the bug are withheld, but exploit code is floating around. Microsoft describes the issue in security bulletin MS15-034. An update (KB3042553) is already available for all supported editions of Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. As a workaround, Microsoft offers disabling IIS kernel caching.

Comments

HTTP.SYS?

[GerbilSoft]

http://support.microsoft.com/e...

In Windows Server 2003 and later versions, Http.sys is the kernel mode driver that handles HTTP requests.

WHY is there a kernel mode driver for HTTP? That's literally begging for security holes.

Re:HTTP.SYS?

[Anonymous Coward]

Because that makes it easier to share information across your lan when all the computers have an "http stack" rather than asking sys admins to install apache or some other dirty hippy app. The downside is that it makes it easier to share information across your lan.

Re:HTTP.SYS?

[Begemot]

WHY is there a kernel mode driver for HTTP? That's literally begging for security holes.

The reasons are clearly described here

Re: HTTP.SYS?

[poizan42]

The user context doesn't really matter when it runs in kernel space as nothing can stop you from just replacing the user context. Why http parsing is done in kernel space is exactly to maximize performance. As mentioned in TFS you can disable it if you want to. One could argue that it shouldn't be on by default because it doesn't give you much if you are serving dynamic content.

Re:HTTP.SYS?

[Anonymous Coward]

HTTP requests are raw user input. You don't want raw user input anywhere near a kernel module.

All network input is raw user input, and all passes through a kernel module before being passed to the application in user mode. With varying levels of parsing of course. After all the kernel handles protocols like TCP IPSec etc. HTTP does seem a particularly complex protocol to implement in the kernel though, meaning more risk of bugs.

If you hadn't put an HTTP handler in the kernel, you wouldn't need a switch of context.

You would. This receives the network request and responds to it from a cached copy without passing the request to the web server. Not doing so would mean a context switch to the server application.

Requests are processed faster because they are routed directly from the kernel to the appropriate user-mode worker process instead of being routed between two user-mode processes.

And there's the real reason it's done - it should say "IPC sucks real bad in Windows, so we made this stupid, stupid, idiotic hack to try and compete with that other OS we're not mentioning."

You are misunderstanding the statement. This is not for IPC (it's for caching static content so useless as such). The 'appropriate user-mode worker[s]' they mean are a caching http proxy and http server. They have moved the caching proxy into the kernel. Of course you could also implement it within the server, but doing it in kernel means even less context switches to respond to a request from the network.

You could do that in a user process.

You could do that in a user process too.

Absolutely. It was done so first. This was purely done as an optimisation for high-volume environments. Doesn't mean it should be on by default.

Re:HTTP.SYS?

[BreakBad]

Still waiting for my kernel level adware module, oh wait, this new feature can do that too! Yay.

Today's security patch is brought to you by Nike!!!

Re:HTTP.SYS?

[ledow]

OSI layering model?

The kernel shouldn't be peering into packets for data. It should (just/only) deal with the TCP packet information (and in a strictly confined way so you don't get things like the age-old flag attacks on TCP packets) and route accordingly.

It shouldn't ever be peering down into the HTTP packet itself and acting upon it as the attack surface is SO MUCH larger on a complicated application protocol.

P.S. What happens if SPDY becomes a standard? How does Microsoft migrate to HTTP/2 etc.? We're talking a KERNEL upgrade for an ever-evolving protocol, and that's just stupid.

But it's a good way to obsolete old OS, no doubt. Sorry, but Server 2008 can't handle HTTP/2 so we're just abandoning it - unless of course you want to turn off kernel-level IIS and run some dog-slow configuration, etc.

Putting something into the kernel just because it could mean less context switches in a particular application is a poor excuse and just shows bad respect for kernel-space.

Having it on by default is suicide.

Re:Why the hell ...

[Just Some Guy]

Why oh why would you put the parsing of HTTP at the kernel level?

They probably saw that FreeBSD has been doing it for 15 years and thought it might be a good idea.

This is the kind of stuff which needs to be in userspace, not the friggin OS.

Apparently not everyone agrees with that.

I'm in no way a Microsoft apologist, but it's not like a senior engineer rolled out of bed one morning, smoked some crack, and yelled "hey, let's break some crap today!" Lots of stuff is done in kernel mode in Linux and the BSDs - like all kinds of graphical mischief - and MS probably does the same things for the same reasons.