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?
• 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.
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].
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?
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?
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.)
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.
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!
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.
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.
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.
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?