Hacker News Reader

Comment by eis | Hacker News Reader

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"

View on HN

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.

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

Sure. My point is that Microsoft isn't the entity to put a web server (or at least components of one) in the kernel. Some may look at it and laugh about how silly that idea is, but in reality many have tried it.

Yep. Another reason folks are against systemd, as it also includes a baked-in http server. Systemd is also poised to become a veritable "second kernel" on linux systems and nobody seems to care enough to stop it.

Isn't systemd an user space process ?

Yes.

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

I agree that systemd is a bad idea in the sense that they are doing too much all at once. It is a fine level of arrogance to assume that there wont be problems along the way :P That being said this thread is about the poor souls who are running IIS servers.

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

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

Haha, I knew somebody would actually look it up :)

Thank you!

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.

I personally worried about the simplicity of the attack. Granted at this stage, its just a DoS, but then take corporate patch cycles into account.. In reality, most aren't going to get patched, at best, for another week or so. Security is still second-fiddle at many companies.

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

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

It would allow the same privileges as the user which is running IIS, usually a "system" account - which equals Administrative privileges.

You two seem to not understand still, please re-read my comment.

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

I actually don't because I have no clue how Windows Server works. So this attack hits the kernel and the context is low level, right?

Not sure if I am not clear enough but yes, it 'hits the kernel and the context is low level'. As low as it can get on Windows.

My windows knowledge is rusty and outdated but... do you mean that code runs in ring 0? that "kernel space"?

Yes

IIS has several components. One of them, the vulnerable part here, is running in kernel space. In kernel space you have access to everything.

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

SYSTEM account is far more powerful than Administrator, especially after Win2008

This page makes it sound easy to go from the one to the other:

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

(not as easy as earlier versions, but still)

that is from 7 years ago...

Sure. I read est as saying that Administrators are more restricted in Server 2008 than they were in earlier Windows versions. I assumed they were talking about the relatively well known technique of scheduling a cmd shell to run as SYSTEM, which that blog mentions being prevented in Server 2008.

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.

Either way you have root level privileges, it's game over...

I would guess it involves spamming the server with specially crafted requests to fill memory with bytecode. After some trial and error (vast simplification) the request from the article could be used to divert the flow of execution into the bytecode spam, rather than causing DoS. The DoS is likely because flow of execution is being diverted to a random area of memory that doesn't contain anything executable, and so crashes instead.

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

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

I had no idea. Madness

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

You haven't read the manpage, have you?

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.

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.

It's the amount of complexity, i.e. the number of things to go wrong.

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.

> 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

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.

I fully agree that the idea doesn't make sense, specially when coupled with memory unsafe languages.

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

Deploying this sort of thing in production on the other hand seems to be a Windows specific idea.

IIS is marketted by MS as a VERY capable web server... typically out-performing other web servers by a large margin. The caching system for IIS has always been one of their crowning achievements, working better than most systems. Though, these days most will put a caching server(or cluster) in front of their operations servers. Just the same, it has worked pretty well. Though I predict this feature will be removed, or disabled by default in future versions.

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

To be honest, the original version of http.sys (XP SP2/Server 2003) dates back to the same period.

I didn't express myself correctly; the latest version of the reference manual is from 2001.

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

That people actually use it is another topic.

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.

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

Yes, but the user/server would have to be running a web server for it to be hit. Usually, that's IIS. But not every windows machine runs a web server.

Nor is every machine's port 80 publicly reachable. Everyone behind a NAT won't be, for example (unless they've explicitly forwarded the port for the purposes of running such a server.)

Nope. WinRM or Power shell seem to use it too. Enabled by default. (Just created a 2012R2 server last night.)

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.

Reply on news.ycombinator.com