News for hackers. Stuff that matters.

A comment on Remote Kernel Code Execution Via HTTP Request In IIS On Windows. Parent comment

Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by IgorPartola on Wednesday April 15, 2015 @09:30AM (#9380804)
To be fair, http://en.wikipedia.org/wiki/TUX_web_server. Having said that, this is huge. This is way worse than Heartbleed for the IIS crowd.
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by psibi on Wednesday April 15, 2015 @09:35AM (#9380841)
From the linked page: "TUX has never been an integrated part of the official Linux kernel, although it has been shipped in some distributions, notably Red Hat, SuSE and Fedora."
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by IgorPartola on Wednesday April 15, 2015 @10:26AM (#9381151)
Sure. My point is that Microsoft isn't the entity to put a web server (or at least components of one) in the kernel. Some may look at it and laugh about how silly that idea is, but in reality many have tried it.
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by na85 on Wednesday April 15, 2015 @03:05PM (#9383325)
Yep. Another reason folks are against systemd, as it also includes a baked-in http server. Systemd is also poised to become a veritable "second kernel" on linux systems and nobody seems to care enough to stop it.
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by psibi on Wednesday April 15, 2015 @04:22PM (#9383812)
Isn't systemd an user space process ?
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by na85 on Wednesday April 15, 2015 @05:11PM (#9384167)
Yes.

It's still on track to becoming a second kernel.

[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by 4ydx on Wednesday April 15, 2015 @08:11PM (#9385111)
I agree that systemd is a bad idea in the sense that they are doing too much all at once. It is a fine level of arrogance to assume that there wont be problems along the way :P That being said this thread is about the poor souls who are running IIS servers.
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by tribaal on Wednesday April 15, 2015 @09:37AM (#9380858)
And how much internet-facing web content is served with this toy webserver exactly?

That's what I thought, none (except maybe the author's blog? wild guess).

[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by icebraining on Wednesday April 15, 2015 @10:22AM (#9381122)
except maybe the author's blog? wild guess

Nope, Ingo Mólnar uses Google+ for his occasional blogging (though the last post seems to be from 2013).

[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by tribaal on Wednesday April 15, 2015 @10:32AM (#9381193)
Haha, I knew somebody would actually look it up :)

Thank you!

[ Parent | on HN ]
[deleted]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by tribaal on Wednesday April 15, 2015 @10:03AM (#9381005)
From that very link, they use IIS (what this CVE is about), not a linux kernel-space http server.
[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by nbevans on Wednesday April 15, 2015 @11:48PM (#9385797)
It really isn't.

OpenSSL's heartbleed was incredibly hard to patch because of the sheer number of products that link to the OpenSSL libraries. It required painstaking effort to ensure everything was running the latest releases. And the severity of Heartbleed was such that all encrypted information could be deciphered.

Whereas this problem... is a simple server crash that can be fixed by running a Windows Update. Not even on the same scale of vulnerability.

[ Parent | on HN ]
Re:Remote Kernel Code Execution Via HTTP Request In IIS On W... by endian01 on Thursday April 16, 2015 @08:19AM (#9387390)
I personally worried about the simplicity of the attack. Granted at this stage, its just a DoS, but then take corporate patch cycles into account.. In reality, most aren't going to get patched, at best, for another week or so. Security is still second-fiddle at many companies.
[ Parent | on HN ]