Slashdot Mirror

← Back to Stories (view on slashdot.org)

Remote Code Execution Vulnerability Found In Windows HTTP Stack

Posted by Soulskill on from the another-day,-another-vuln dept.

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.

31 of 119 comments (clear)

  1. I'm running Windows ... by cablepokerface · · Score: 2, Funny

    ... so there is a solid 'no carrier' joke in there, I just can't think of o[NO CARRIER]

  2. HTTP.SYS? by GerbilSoft · · Score: 5, Informative
    http://support.microsoft.com/e...

    In Windows Server 2003 and later versions, Http.sys is the kernel mode driver that handles HTTP requests.

    WHY is there a kernel mode driver for HTTP? That's literally begging for security holes.

    1. Re:HTTP.SYS? by Anonymous Coward · · Score: 5, Funny

      Because that makes it easier to share information across your lan when all the computers have an "http stack" rather than asking sys admins to install apache or some other dirty hippy app. The downside is that it makes it easier to share information across your lan.

    2. Re:HTTP.SYS? by abies · · Score: 4, Insightful

      Bundling http support with OS distribution is one thing. Making it _kernel_ module is different thing altogether.

    3. Re:HTTP.SYS? by poizan42 · · Score: 4, Informative

      > IIS kernel caching For performance reasons probably. It's optional though. I have no idea about real numbers, but there is always some overhead associated with contex switches which may be reduced if the http stream is assembled in chunks in kernelspace and control is only switched to userspace when a chunk is ready. Also it may be possible to parse the http stream directly from the buffer that the hardware writes the received data to without the overhead of copying the packets to userspace.

    4. Re:HTTP.SYS? by Begemot · · 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

    5. Re: HTTP.SYS? by poizan42 · · Score: 5, Informative

      The user context doesn't really matter when it runs in kernel space as nothing can stop you from just replacing the user context. Why http parsing is done in kernel space is exactly to maximize performance. As mentioned in TFS you can disable it if you want to. One could argue that it shouldn't be on by default because it doesn't give you much if you are serving dynamic content.

    6. Re:HTTP.SYS? by Dr_Barnowl · · 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."

    7. Re:HTTP.SYS? by PPH · · Score: 4, 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.

      --
      Have gnu, will travel.
    8. Re:HTTP.SYS? by Anonymous Coward · · 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.

    9. Re:HTTP.SYS? by BreakBad · · 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!!!

    10. Re:HTTP.SYS? by Anonymous Coward · · Score: 3, Insightful

      You mean where it was removed from the kernel into userspace because everyone realized it was a bad idea?

    11. Re:HTTP.SYS? by ledow · · 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.

    12. Re:HTTP.SYS? by poizan42 · · Score: 4, Informative

      Turns out it's not actually on by default. You have to add a caching rule and check the "Enable Kernel Caching" checkbox.

    13. Re: HTTP.SYS? by poizan42 · · Score: 3, Informative

      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.

    14. Re:HTTP.SYS? by Anonymous Coward · · 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. "

    15. Re:HTTP.SYS? by NetCow · · Score: 3, Informative

      It's on by default in 2008, 2008R2, Vista, 7. Quoth Enable Kernel Caching (IIS 7):

      Note: By default, kernel caching is enabled in IIS 7.

    16. Re: HTTP.SYS? by deek · · Score: 2

      Actually, according to the Microsoft Technet article linked in the story, kernel caching is enabled by default in IIS 7.

  3. Why the hell ... by gstoddart · · Score: 4, 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.

    --
    Lost at C:>. Found at C.
    1. Re:Why the hell ... by Z00L00K · · Score: 3, 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.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:Why the hell ... by Grishnakh · · 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.

    3. Re:Why the hell ... by wonkey_monkey · · Score: 2

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

      --
      systemd is Roko's Basilisk.
    4. Re:Why the hell ... by Just+Some+Guy · · 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 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.

      --
      Dewey, what part of this looks like authorities should be involved?
    5. Re:Why the hell ... by Zordak · · Score: 3, 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?

      --

      Today's Sesame Street was brought to you by the number e.
  4. Hmm by koan · · 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";

    --
    "If any question why we died, Tell them because our fathers lied."
    1. Re:Hmm by jo_ham · · Score: 2, 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?

  5. Don't see what the big deal is... by alexjplant · · Score: 4, Funny

    Just REM it out of your AUTOEXEC.BAT, flip the power clunker... er, switch, then flip it back on. Problem solved! Nobody will be able to h4x0r your beige box ever again! ...oh, sorry. I saw .SYS and thought we were stuck in 1996 AD.

    1. Re:Don't see what the big deal is... by Anonymous Coward · · 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.

  6. Who's laughing now? by AndyKron · · Score: 2, Insightful

    Most people laugh at the Amish, but they're laughing at us.

    1. Re:Who's laughing now? by NotInHere · · Score: 2

      Who's laughing now?

      Linux users.

  7. Re:This was already covered... by wonkey_monkey · · Score: 2

    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.

    --
    systemd is Roko's Basilisk.