Remote Code Execution Vulnerability Found In Windows HTTP Stack 119
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.
I'm running Windows ... (Score:2, Funny)
HTTP.SYS? (Score:5, Informative)
WHY is there a kernel mode driver for HTTP? That's literally begging for security holes.
Re:HTTP.SYS? (Score:5, Funny)
Re:HTTP.SYS? (Score:5, Insightful)
Bundling http support with OS distribution is one thing. Making it _kernel_ module is different thing altogether.
Re: (Score:3, Insightful)
Re: HTTP.SYS? (Score:1)
So it needs to run as System? It makes no sense to have http parsing in kernel space unless they were edging for performance. This should be at best a user space dll.
Re: HTTP.SYS? (Score:5, Informative)
Re: (Score:3, Informative)
Re: (Score:1)
Let me correct myself here - it's not even on by default. You have to actually check a "Enable Kernel Caching" checkbox to turn it on. People are spending way too much time bashing a feature that's opt-in.
I did not opt-in and it is on, I checked several of our IIS Web servers all have it turned on and we did not opt-in to that.
Re: (Score:3)
Actually, according to the Microsoft Technet article linked in the story, kernel caching is enabled by default in IIS 7.
Re: (Score:2)
You could have apache installed by default (witness MacOS X) and run from userspace, you don't need it in the kernel by default.
Re: (Score:2)
Internet-facing service running as SYSTEM.
Re:HTTP.SYS? (Score:5, Funny)
Still waiting for my kernel level adware module, oh wait, this new feature can do that too! Yay.
Today's security patch is brought to you by Nike!!!
Re:HTTP.SYS? (Score:4, Informative)
Re:HTTP.SYS? (Score:5, Informative)
WHY is there a kernel mode driver for HTTP? That's literally begging for security holes.
The reasons are clearly described here [microsoft.com]
Re:HTTP.SYS? (Score:4, Insightful)
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."
Re:HTTP.SYS? (Score:5, Informative)
HTTP requests are raw user input. You don't want raw user input anywhere near a kernel module.
All network input is raw user input, and all passes through a kernel module before being passed to the application in user mode. With varying levels of parsing of course. After all the kernel handles protocols like TCP IPSec etc. HTTP does seem a particularly complex protocol to implement in the kernel though, meaning more risk of bugs.
If you hadn't put an HTTP handler in the kernel, you wouldn't need a switch of context.
You would. This receives the network request and responds to it from a cached copy without passing the request to the web server. Not doing so would mean a context switch to the server application.
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."
You are misunderstanding the statement. This is not for IPC (it's for caching static content so useless as such). The 'appropriate user-mode worker[s]' they mean are a caching http proxy and http server. They have moved the caching proxy into the kernel. Of course you could also implement it within the server, but doing it in kernel means even less context switches to respond to a request from the network.
You could do that in a user process.
You could do that in a user process too.
Absolutely. It was done so first. This was purely done as an optimisation for high-volume environments. Doesn't mean it should be on by default.
Re:HTTP.SYS? (Score:5, Insightful)
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.
Re:HTTP.SYS? (Score:4, Informative)
Re: (Score:2)
I have never ticked that box.
Yet my servers have it on.
I'm not saying you're lying, but something, somewhere turned that on and it wasn't me.
Re: (Score:3, Informative)
According to this page IT IS on by default.
https://technet.microsoft.com/en-us/library/cc731903%28v=ws.10%29.aspx
"By default, kernel caching is enabled in IIS 7. "
Re: (Score:3, Informative)
It's on by default in 2008, 2008R2, Vista, 7. Quoth Enable Kernel Caching (IIS 7) [microsoft.com]:
Note: By default, kernel caching is enabled in IIS 7.
Re: (Score:1)
I completely agree with you that doing complex parsing in the kernel is stupid. And I'll make your day just that little bit worse:
Remember TTF and OTF which evolved into WOFF? Those flexible but very complex font file formats, optionally with bytecode that's actually JITted? That can be embedded into webpages therefore are interpreted by the underlying font rendering services regardless of browser used?
Windows parses them in the kernel.
Re:HTTP.SYS? (Score:5, Insightful)
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.
Re: (Score:2)
The bug here affects the HTTP server side, not IE.
And in HTTP servers, there are LOT of context switches - in basic static file handling mode, you read a file (syscall to read file), then you write it to
Re: (Score:2)
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.
If your context switches are too slow, the correct solution is to fix the kernel or add syscalls to reduce the overhead (see sibling post). Moving parts of your application into kernel-space is bad design no matter how you look at it. (Besides, wasn't it only a few years ago they had a vulnerability in their kernel-mode font driver?)
*ahem* (Score:2)
Did you forget about kHTTPd?
Re: (Score:1)
Nope, but you're comparing apples to electric chairs, and here's why:
"kHTTPd handles only static (file based) web-pages, and passes all requests for non-static information to a regular userspace-webserver such as Apache or Zeus."
IIRC, The 'doze version tries to handle and serve *all* requests, for *anything* httpd-related (because, as an above poster had aptly mentioned, Windows IPC basically blows goats.)
Re: (Score:1)
Re: (Score:2)
I have been told that Windows NT uses a microkernel, that it delegates most of its tasks to lower privileged processes. Now I hear that windows does http parsing in kernel space. HTTP PARSING. Not even systemd manages to do this. I would expect design descisions like this for DOS, but not for an OS that claims to have a microkernel.
Staying with my "monolithic" penguin OS.
Re: (Score:1)
Because competing on an even playing field is hard (Score:2)
Microsoft introduced HTTP.SYS in Server 2003 to improve IIS 6.0 performance. They really wanted to beat Apache.
Each application pool has a dedicated request queue in HTTP.SYS, which provides very fast and low-latency network performance. This advantage may have been more significant on the slower machines of the time than it is today.
I am not a web developer or web admin, so I don't know how important the performance is---but I doubt it outweighs the security shortcomings.
As other OS functions (such as Wind
Re: (Score:2)
Because MS OS "architecture" sucks and they cannot match the performance of the competition without dirty tricks. These tricks come at a high price with regards to security.
Re: (Score:2)
1) Literally?
2) This is actually pretty common, witness the TUX [wikipedia.org] Linux kernel web server a few years ago.
Why? the same reason anything is dumped into kernel mode. Speed. Got a few thousand hits per second? Drop your userspace code into kernel space, and now you're eliminating a few thousand user-kernel space swap outs per second. Problems? Yeah, lets have a fairly complicated protocol that is designed to be poked at (and therefore hacked at) remotely dropped into the kernel. That and complicated data st
Why the hell ... (Score:5, Informative)
Why oh why would you put the parsing of HTTP at the kernel level?
Why does Microsoft consistently fail to understand that if you make something inherent to the OS it becomes a bigger security risk?
This just makes no sense to me, no more than embedding IE so deeply into the OS they said they couldn't remove it.
This is the kind of stuff which needs to be in userspace, not the friggin OS.
Re:Why the hell ... (Score:4, Interesting)
It's easier that way - no need to be concerned with rights management. You can also get performance benefits from having it as a kernel driver.
But we also see the disadvantages - security holes.
I suspect that this also influences Windows XP, and it's quite interesting that a lot of ATMs and other embedded systems still uses XP.
Re: (Score:2)
Given Windows Server 2003 is vulnerable but no mention of Windows 2000, the only version of XP that would likely be affected would be the x64 version, which was built on 2K3 Server. Vanilla XP was built on Windows 2000.
Re: (Score:3)
I wouldn't count on that logic:
The following software versions or editions are affected. Versions or editions that are not listed are either past their support life cycle or are not affected.
XP and 2000 certainly fall into one of those categories...
Re: (Score:1)
Re: (Score:1)
Re: (Score:2, Insightful)
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.
Re: (Score:1)
Exactly. This lackadaisical attitude towards security is par for the course with them.
Re: (Score:1)
Another typical Microsoft shill. How much do they pay you to sit around and troll message boards?
Re: (Score:2)
Give it up already. You really think there are paid shills on this poor excuse for a website? How many visitors does Slashdot get per day compared to some place like Reddit? I'm sure Linux will be the dominant desktop OS any decade now.
Re: (Score:2)
Re:Why the hell ... (Score:5, Informative)
Why oh why would you put the parsing of HTTP at the kernel level?
They probably saw that FreeBSD has been doing it for 15 years [freebsd.org] and thought it might be a good idea.
This is the kind of stuff which needs to be in userspace, not the friggin OS.
Apparently not everyone agrees with that.
I'm in no way a Microsoft apologist, but it's not like a senior engineer rolled out of bed one morning, smoked some crack, and yelled "hey, let's break some crap today!" Lots of stuff is done in kernel mode in Linux and the BSDs - like all kinds of graphical mischief - and MS probably does the same things for the same reasons.
Re:Why the hell ... (Score:4, Funny)
but it's not like a senior engineer rolled out of bed one morning, smoked some crack, and yelled "hey, let's break some crap today!"
How else do you explain WindowsME and Vista?
Re: (Score:2)
How else do you explain WindowsME and Vista?
I don't, and neither can anyone else.
Re: (Score:2)
Though I thought of this too, it's a majorly different level of parsing, and therefore much smaller attack surface.
MS has a full HTTP stack in the kernel. FreeBSD accept filters (including the http_filter) do a minimal check, then pass the full request to userspace - no heavy parsing in the kernel. I think the http_filter just looks for GET/HEAD/WHATEVER_SCHEME and a few other minimal things, and
Re: (Score:2)
Re: (Score:1)
Hmm (Score:2)
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";
Re: (Score:2)
And the problem is - that's a well-documented problem with other web servers historically and quite simple bounds-checking at fault there.
Seriously,MS, audit your damn basics occasionally.
I always shudder when I think of the MS software operating on the frontline of a businesses Internet connection.
Re: (Score:1)
Me too! Me too!
Re: (Score:3, Insightful)
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?
Re: (Score:1)
What else did you want them to do to prove they were taking the exploit seriously?
Well I'm not writing a book for you, and someone else already covered an example.
Why don't you tell me the answer to your questions.
Re: (Score:1)
What else did you want them to do to prove they were taking the exploit seriously?
Well I'm not writing a book for you, and someone else already covered an example.
Why don't you tell me the answer to your questions.
This isn't a test. What is this? High school?
The fact that you're being acutely defensive suggests to me that you just wanted to engage in some good old fashioned Microsoft bashing with nothing constructive to add in the safety of slashdot.
As far as how I would answer my own question, based on my original assertion that they have already taken it seriously; nothing.
However, since you suggested that they have not taken the exploit seriously enough, I wondered how exactly our positions differed (since I can't
Re: (Score:1)
Or am I...
Re: (Score:2)
char request1[] = "GET / HTTP/1.1\r\nHost: stuff\r\nRange: bytes=0-18446744073709551615\r\n\r\n";
Brings back old memories of web servers losing their marbles after seeing post requests with maliciously selected content-length headers. Guess some never learn.
Re: (Score:1)
I miss winnuke and IRC.
Comment removed (Score:4, Funny)
Re: (Score:2, Informative)
"Windows NT" includes basically... every Windows OS since 1993 to date; including Windows 10 that hasn't even come out yet.
So, no. It wasn't EOL'd, as you so put it.
Re: Don't see what the big deal is... (Score:2)
Re: (Score:1)
Re: (Score:2)
You joke, but some parts of Windows actually are stuck in 1996. And that's not even getting into userspace apps.
This was already covered... (Score:1)
Re: (Score:3)
This was already covered...
It wasn't covered. It looks like your submission didn't make it out of the firehose, probably because, to be bluntly honest, it's not very well written.
Re: (Score:2)
Who's laughing now? (Score:2, Insightful)
Re: (Score:3)
Who's laughing now?
Linux users.
Re: (Score:1)
The Amish have REALLY slow web servers. The latency of those horse-drawn wagons is really bad, but on the bright side they are pretty big so the bandwidth is good if you use really small type on the hand-operated printing press.
Also, kernel panics are rare-- usually just when it's the end of the corn growing season, and some idiot on a motorcycle spooks the horse.
A flaw in *WINDOWS*?! (Score:2)
Re: (Score:2)
I have been saying this for years and I almost believe it myself now.
The fact is, I have biases and these biases shift over time.
I always tell myself that I am giving people the best advice I can, but upon self analysis, I hardly ever recommend MACs to people because I just sort of don't like Apple because of encounters I have had over the years with zealot fanboys. I sort of have the same feelings toward Cisco.... every Cisco tech I have ever met looked down their nose at me... for that rea
Re: (Score:2)
I totally get the issues with zealotry amongst Apple users. I have a friend who thinks Apple can do no wrong; he's one of the brightest people I
Re: (Score:2)
Somehow, Heartbleed and Shellshock mattered, even though they were patched the very same day they were disclosed, but this doesn't matter for the same reason?
As for your claim of purest bullshit, I'm pretty sure the summary clarified that there was a patch already available by stating:
An update (KB3042553) is already available
with the caveat of only being 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
Looks like the ~17% of users still on XP are boned this time. I see why you say the *NIX "trolls" don't have a valid point here, though, I mean only nearly 1/5 of all computers, globally, will remain unpatched.
Re: (Score:2)
Also - See subject? Good! "Drink it in, & digest it"...
I've been off of XP for years, but nearly 1/5 of computers still use it. I don't see how you can say it doesn't matter that nearly 1/5 of computers in the world will go unpatched.
This article makes it SOUND as if it's "just happened & wasn't patched"
And the summary (which is what most of us read anyway) does not. The first two words of the article article (actually some guy's blog post) are "Patching time." That's followed by a quote from the MSSB about the exploit, then "Details are withheld for now, so it's a race: patch your systems before the attackers can reverse engineer
Re: (Score:2)
See subject & that quoted from you above: I merely stated fact (get over it).
What fact, that XP is no longer supported? I never argued that. I also stated a fact: XP is still used on ~17% of computers worldwide. I'll let you (Mr. Security Guy) soak that up.
Don't you have something BETTER to show for yourself than this
No, you don't... & you never will - you don't have the skills necessary to create something that good )
I hope you choke to death on your ego. You don't know me, nor what skills I have; did it ever cross your mind that I'm not some egomaniac, like you, who needs to flaunt my "skills" to feel good about myself? Only my employer, clients, and prospective clients (none of which includes you) need to know that. Your app looks like a pie