It's still on track to becoming a second kernel.

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

Nope, Ingo Mólnar uses Google+ for his occasional blogging (though the last post seems to be from 2013).

Thank you!

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.

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

The heap spraying is the missing puzzle piece from the article.

The point is this is allowing code execution within the kernel of windows. It doesn't even reach the IIS userland process.

The title was giving people the wrong impression about the severity of the vulnerability. This has nothing to do with "avoid giving people ideas" which would be stupid anyways.

As far as I know, IIS is the only(bar embedded devices running a single address space OS and various ancient/obsolete toys servers on linux) used in production that handles part of HTTP in kernel space (or ring 0 if you will).

http://blogs.technet.com/b/askds/archive/2008/10/22/getting-...

(not as easy as earlier versions, but still)

But you would still expect an Administrator account to be able to load files onto the system, so obtaining the SYSTEM shell remains pretty easy.

The distinction between SYSTEM and Administrator was a convenience, and if I understood est correctly, it still is.

I had no idea. Madness

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.

Handling TCP/IP in the kernel requires substantially less complexity than handling HTTP/TCP/IP.

And even then, there are efforts (GNU Hurd, for instance) to push things like TCP out of the kernel level.

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.

The idea is completely different.

accf_http is... here, just read the source: https://github.com/freebsd/freebsd/blob/master/sys/netinet/a... – if it sees something that looks like an HTTP request and delays returning to userspace until \r\n\r\n.

http.sys is an actual HTTP/1.x parser. That runs in ring 0.

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

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

Just wanted to make the point it isn't a Windows specific idea.

I'm kind of surprised this issue wasn't discovered previously. Fortunately, there doesn't seem to be an exploit beyond crashing the server yet (which is bad enough). (sigh, kind of glad I'm in the process of migrating everything away from IIS).

That people actually use it is another topic.

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

Plus if you have reservations created with HTTP.SYS, your app doesn't even have to be running. A friend tried turning off IIS, but port 80 would still respond.