Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Windows Bug Security IT

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.
This discussion has been archived. No new comments can be posted.

Remote Code Execution Vulnerability Found In Windows HTTP Stack

Comments Filter:
  • ... so there is a solid 'no carrier' joke in there, I just can't think of o[NO CARRIER]
  • HTTP.SYS? (Score:5, Informative)

    by GerbilSoft ( 761537 ) on Wednesday April 15, 2015 @10:25AM (#49478125)
    http://support.microsoft.com/e... [microsoft.com]

    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.

    • by Anonymous Coward on Wednesday April 15, 2015 @10:30AM (#49478167)
      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.
      • Re:HTTP.SYS? (Score:5, Insightful)

        by abies ( 607076 ) on Wednesday April 15, 2015 @10:34AM (#49478207)

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

      • by Anonymous Coward

        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)

          by poizan42 ( 1689384 ) on Wednesday April 15, 2015 @10:46AM (#49478329)
          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.
          • Re: (Score:3, Informative)

            by poizan42 ( 1689384 )
            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.
            • by Anonymous Coward

              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.

            • by deek ( 22697 )

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

      • You could have apache installed by default (witness MacOS X) and run from userspace, you don't need it in the kernel by default.

    • by ledow ( 319597 )

      Internet-facing service running as SYSTEM.

    • Re:HTTP.SYS? (Score:4, Informative)

      by poizan42 ( 1689384 ) on Wednesday April 15, 2015 @10:40AM (#49478265)
      > 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.
    • Re:HTTP.SYS? (Score:5, Informative)

      by Begemot ( 38841 ) on Wednesday April 15, 2015 @10:46AM (#49478321)

      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)

        by Dr_Barnowl ( 709838 ) on Wednesday April 15, 2015 @10:57AM (#49478431)

        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)

          by Anonymous Coward on Wednesday April 15, 2015 @11:13AM (#49478587)

          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)

            by ledow ( 319597 ) on Wednesday April 15, 2015 @12:05PM (#49479141) Homepage

            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)

              by poizan42 ( 1689384 ) on Wednesday April 15, 2015 @01:08PM (#49479669)
              Turns out it's not actually on by default. You have to add a caching rule and check the "Enable Kernel Caching" checkbox.
              • by ledow ( 319597 )

                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)

                by Anonymous Coward

                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)

                by NetCow ( 117556 )

                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.

            • by NetCow ( 117556 )

              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)

        by PPH ( 736903 ) on Wednesday April 15, 2015 @11:04AM (#49478497)

        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.

        • by tlhIngan ( 30335 )

          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.

          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

        • by rdnetto ( 955205 )

          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?)

    • Did you forget about kHTTPd?

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

        ...from the kHTTPd site page, right up front.

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

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

      • Pretty much everything you have just said is wrong. NT is not a microkernel, and if it ever was, it stopped being do by NT 4.0. And the parsing is not done in kernel space. HTTP.SYS is not a parser, it is a listener.
    • 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

    • by gweihir ( 88907 )

      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.

    • 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)

    by gstoddart ( 321705 ) on Wednesday April 15, 2015 @10:31AM (#49478177) Homepage

    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)

      by Z00L00K ( 682162 ) on Wednesday April 15, 2015 @10:40AM (#49478273) Homepage

      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.

      • by Khyber ( 864651 )

        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.

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

        • No, Windows 2000 Professional was built on Windows 2000.
      • by Anonymous Coward
        According to an interview with a developer of windows, "this was done to entirely for performance reasons"
    • Re: (Score:2, Insightful)

      by Grishnakh ( 216268 )

      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.

    • This may be one unfortunate result of Bill Gates integrating IE deeply into Windows in order to crush Netscape, and not be nailed by the Feds for doing so in United States v. Microsoft Corporation in 2001.
    • Re:Why the hell ... (Score:5, Informative)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday April 15, 2015 @02:02PM (#49480107) Homepage Journal

      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.

      • by Zordak ( 123132 ) on Wednesday April 15, 2015 @04:45PM (#49481225) Homepage Journal

        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?

      • They probably saw that FreeBSD has been doing it for 15 years [freebsd.org] and thought it might be a good idea.

        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

        • That's true, but I see it as a matter of degree. Windows does a lot more, sure, but FreeBSD is still doing some HTTP parsing in a kernel module.
    • They're not parsing HTTP in the kernel. HTTP.SYS is a listener.
  • by koan ( 80826 )

    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";

    • by ledow ( 319597 )

      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:3, Insightful)

      by jo_ham ( 604554 )

      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?

      • by koan ( 80826 )

        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.

        • by jo_ham ( 604554 )

          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

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

  • by alexjplant ( 3458309 ) on Wednesday April 15, 2015 @10:56AM (#49478427)
    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.
    • 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.

  • by AndyKron ( 937105 )
    Most people laugh at the Amish, but they're laughing at us.
    • Who's laughing now?

      Linux users.

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

  • For all the trolls that keep screaming about how insecure Linux is when a vulnerability is discovered in something like Bash (which is used by the BSDs, including OSX, and can also run on Windows), OpenSSL (a library used by many applications which run on many platforms, but not used by Linux itself), or any other library or application capable of running on the platform, please allow me to take thos opportunity to point out that this is a critical vulnerability in Windows itself and not just some 3rd-party
    • 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

      • That may be true for most people, but as someone who uses *all* of the tools, I can tell you I'm certainly using the ones that work best. Your Cisco example is weak simply for the fact that part of "working" is being supported comfortably, which is clearly not the case for you when it comes to Cisco gear, so Cisco simply doesn't work for you. That's fair, as well.

        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

May all your PUSHes be POPped.

Working...