Slashdot Mirror
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.
Bundling http support with OS distribution is one thing. Making it _kernel_ module is different thing altogether.
And they're fucking stupid reasons.
HTTP requests are raw user input. You don't want raw user input anywhere near a kernel module.
Kernel-mode caching. Requests for cached responses are served without switching to user mode.
If you hadn't put an HTTP handler in the kernel, you wouldn't need a switch of context.
Kernel-mode request queuing. Requests cause less overhead in context switching, because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.
You could do that in a user process.
When a worker process fails, service is not interrupted; the failure is undetectable by the user because the kernel queues the requests while the WWW service starts a new worker process for that application pool.
You could do that in a user process too.
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."
I disagree; I applaud MS's decision to put it in the OS kernel, and I think they should move more stuff there, security be damned. I just wish they'd be more honest and tell everyone that they really don't care about security.
Then, anyone who continues to use MS products will get what they deserve.
The reasons are clearly described here
I read through that and didn't see anything about "We're all idiots".
Their reasons involve context switching and interprocess communications. Context switching has got to happen (unless they run IE in kernel space) so just get it over with. Interproces communication has always been a weakness in Microsoft systems. Since day one. Multitasking OSs are here, folks. Get over DOS.
Have gnu, will travel.
Most people laugh at the Amish, but they're laughing at us.
I'm against "withholding details" if anything there should be an established web page that release the exploit as soon as it is found FORCING M$ and Apple to take it more seriously.
char request1[] = "GET / HTTP/1.1\r\nHost: stuff\r\nRange: bytes=0-18446744073709551615\r\n\r\n";
How are they not taking it seriously? The summary mentions that patches are already available, plus a method to prevent the exploit occurring on a non-patched machine.
What else did you want them to do to prove they were taking the exploit seriously?
You mean where it was removed from the kernel into userspace because everyone realized it was a bad idea?
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.