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"
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.
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.
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).
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.
I have trouble understanding what you want to say but I did not say what you quoted me with. Please don't put words in my mouth.
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.
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).
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.
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.
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.
Yeah, I completely missed that in order for kernel caching to work, HTTP has to be parsed within the kernel, and so I was making an invalid point. It happens.
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.
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).
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:
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.
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.)
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"