
Vulnerability in HTTP.sys Could Allow Remote Code Execution - runesoerensen
https://technet.microsoft.com/library/security/ms15-034
======
blinkingled
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?

~~~
ComputerGuru
It's actually not "still has" \- this was a major feature that brought
significant performance improvements and something they pushed hard for:
[http://www.microsoft.com/technet/prodtechnol/WindowsServer20...](http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a2a45c42-38bc-464c-a097-d7a202092a54.mspx?mfr=true)

(Not saying I agree or disagree, just saying that this isn't so much an
ancient artifact as it is a fairly recent and purposeful addition.)

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

~~~
enigmo
It has TransmitFile and TransmitPackets: [https://msdn.microsoft.com/en-
us/library/windows/desktop/ms7...](https://msdn.microsoft.com/en-
us/library/windows/desktop/ms740565\(v=vs.85\).aspx)

They were in use (at least TransmitFile was) by IIS long before http.sys was
conceived.

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

Anybody else have anything to share?

[1] [https://www.snort.org/advisories/vrt-
rules-2015-04-14](https://www.snort.org/advisories/vrt-rules-2015-04-14)

~~~
adsche
Seems to be this:
[https://twitter.com/NexusFandom/status/588254994203303937/ph...](https://twitter.com/NexusFandom/status/588254994203303937/photo/1)

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

That's pretty scary

~~~
jj10
WinRM (AKA PowerShell Remoting) uses HTTP.sys and is on by default on server
SKUs.

~~~
Jayku1
WinRM and PowerShell Remoting do not use Kernel Mode Caching, and are
therefore not vulnerable.

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

1\. [http://azure.microsoft.com/en-
us/documentation/articles/clou...](http://azure.microsoft.com/en-
us/documentation/articles/cloud-services-guestos-update-matrix/) 2\.
[http://azure.microsoft.com/en-
us/documentation/articles/clou...](http://azure.microsoft.com/en-
us/documentation/articles/cloud-services-guestos-msrc-releases/)

~~~
shanselman
I'm told it's already done.

~~~
jbrantly
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!

------
tdicola
Ouch, hopefully doesn't turn into blaster 2.0. These days you're just asking
for trouble if port 80 is open and you don't have a need for it, though.

~~~
gtirloni
Couldn't parse the vulnerability name. Do you have a CVE number where I can
find technical details about that?

~~~
mukyu
Blaster[0] was a worm. It used CVE-2003-0352.[1]

[0]
[http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29](http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29)

[1] [http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2003-0352](http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2003-0352)

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

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

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

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

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

------
rsalt
Do we know exactly what kind of packets lead to such remote code execution ?

------
jaytaylor
What is the actual windows service that is involved/vulnerable?

~~~
xfr
It's IIS.

~~~
MichaelGG
It says HTTP.SYS. Which is IIS if listening on HTTP, and anything else that
uses the HTTP API (like .NET's HttpListener).

It's so awesome when you move HTTP stacks into the kernel, where they rightly
belong.

~~~
aioprisan
This. I can't believe how bad of an idea this was.

------
simplexion
...but I just finished updating my servers!

~~~
krapp
Apparently you didn't.

