31–40 of 201 posts
Earlier quoted context omitted.
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.
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).
At least for us. DHS/NSA already has them thanks to Microsoft's renewed commitment to share "cyber-threat" data with them (a.k.a zero-days).
Earlier quoted context omitted.
It'll be the second, I'm afraid. Only Windows Servers running IIS should be vulnerable, maybe the post didn't make that entirely clear.
According to comments in the other discussion here about this it might not IIS be only, because that kernel component is used for other HTTP services as well: https://news.ycombinator.com/item?id=9378449
I tried to send the bad curl request to our servers (test env, obviously) and I didn't get any error. It seems I should be getting "Requested Range Not Satisfiable" if the server is vulnerable and "The request has an invalid header name" if it's patched. I'm getting neither, simply a normal response HTTP 200 with the requested page. Anyone knows how to really test it? EDIT : It is indeed related to "Output Cache" set…
Earlier quoted context omitted.
You two seem to not understand still, please re-read my comment. The point is this is allowing code execution within the kernel of windows. It doesn't even reach the IIS userland process.
My windows knowledge is rusty and outdated but... do you mean that code runs in ring 0? that "kernel space"?
Earlier quoted context omitted.
You two seem to not understand still, please re-read my comment. The point is this is allowing code execution within the kernel of windows. It doesn't even reach the IIS userland process.
I actually don't because I have no clue how Windows Server works. So this attack hits the kernel and the context is low level, right?
But wait, I thought Micro$oft were lauded as having "got" security these days? Surely it is isn't so!
But wait, I thought Micro$oft were lauded as having "got" security these days? Surely it is isn't so!
They pretty much have. Sometimes people make mistakes that lead to vulnerabilities like this. It will be patched soon, then forgotten, and life will return to normal for everyone using IIS. We'll still run http in the kernel for performance purposes and everyone will conclude that no damage was really done. People will still use the same tech.. this vulnerability is not game changing and it'll be business as normal.
But I agree, lessons won't be learnt, braindead ideas like in kernel http will persist, and windows users will continue to pay over and over (in terms of insecurity, as well as cash)
I tried to send the bad curl request to our servers (test env, obviously) and I didn't get any error. It seems I should be getting "Requested Range Not Satisfiable" if the server is vulnerable and "The request has an invalid header name" if it's patched. I'm getting neither, simply a normal response HTTP 200 with the requested page. Anyone knows how to really test it? EDIT : It is indeed related to "Output Cache" set…
Are you sure that curl is sending the request properly? (Check with tcpdump)
I read the microsoft security bulletin and it says that your IIS server is protected if Kernal Caching is off, maybe that's why our servers are neither blocking the request nor crashing with the request.