the bluescreen is because, well, "CRITICAL_OBJECT_TERMINATION". in Windows, some processes, if they terminate, cause the entire operating system to stop with a bugcheck. think of it like init dying in linux.
there sadly is no 'stack backtrace'. it looks like he's managed to send some message to csrss.exe that caused it to crash with an invalid memory operation.
this is bad, it might even be exploitable. even though the exploit would be in csrss, which is not kernel mode, it's still extremely important and trusted. also, untrusted low-user code could make this call to privilege escalate.
it's worth noting that thought the author states " I stumbled accross the bug inadvertently while working on something totally unrelated to security, and decided to publish my findings so that this can be fixed by Microsoft.", microsoft actually has a security team that can be found here: http://technet.microsoft.com/en-us/security/ff852094.aspx (google for "microsoft report security bug")
the bugs you report to them remain confidential until they are fixed. this way, potentially bad exploit code isn't floating around the internet for some indeterminate amount of time. like this!
a trouble here is that the original fault is in user-mode csrss. you cannot use a user-mode debugger to debug csrss, so, to debug it you must use a kernel debugger. the process is involved. it is documented by microsoft though...
another trouble is that it seems that, at least on my systems, the ability to create a full dump of memory from the faulting process has been removed in w7. all you can do now is dump kernel mode memory, which would not include the needed information...
This isn't really an exploit, except insofar as a local user can cause a DoS for the system. Until there's a demonstration that arbitrary code can be invoked with elevated privileges, it's just a bug.
You can cause a blue screen by trying to copy the device context of the screen to itself with BitBlt - a stupid thing to do but still causes a blue screen
Untill proven otherwise this totally violates full Disclosure policies. I know they are like 'gentleman agreements' but this feels bad, and looks bad, like the author is only out for some internet fame. I can not believe that he in any way tried to contact Microsoft, but clearly took his time on this publication.
I kind of get the feeling that the author doesn't really know what he's doing. The actual exploit code is a fragment of what looks like a 'hello world' sort of console IO test. The 0xC0000000 he goes on and on about is just GENERIC_READ | GENERIC_WRITE, which is a totally legal combination. And he disassembles his own code for no particularly good reason.
Given all of this, it's not really a surprise that he's not clear on responsible disclosure policies (this doesn't really violate 'full disclosure policies' - he's fully disclosing it, after all!). It sounds like he was just playing around with things, found a way to crash his own machine by accident, and decided to post it online.
I also note that the code is incomplete, and looks reasonably straightforward and correct from casual inspection. I wonder if the real cause is elsewhere?
I haven't exactly pinpointed the cause of the problem, I just noted that that call was the last point in my code to get executed before the system was hosed.
Also, the code is complete: check the tarball listed at the end of the page.
There are tons of developers who've got no experience dealing with (potential) security issues or have any idea about the "gentleman agreements" that are prevalent in the security- versus the IT-industry. So it could very well be that he has no idea what he's doing.
Then again; every 12 months or so the debate regarding full/responsible/no disclosure flares up again in the security-/IT-industry after another public outcry regarding one specific bug, company or patch. In the end nothing is resolved and we still continue to rely on gentleman agreements.
<secure@microsoft.com>: host
microsoft-com.mail.protection.outlook.com[207.46.100.11] said: 550 5.7.1
Service unavailable; Client host [66.175.217.21] blocked using Blocklist 1;
To request removal from this list please forward this message to
delist@messaging.microsoft.com (in reply to RCPT TO command)
Perhaps but it also increases the probability that a possible security issue gets exploited. I suspect the author just wants publicity first. Ego talks.
You get better security back for all the Windows machines that are in your local network, the ones that your customers use or the Windows/Azure servers you use for your day to day business.
If you dump it online way more people start looking at it. They might be able to turn it into a reliable exploit leaving you, your customers and your servers at risk.
But the last thing HN needs is another debate on the pro's and cons of full disclosure; that's been done to death in the past decade all over the web :)
OK, conversely, you're saying that you should do the wrong thing (as in this case), if there is no financial incentive?
Given you aren't going to get a reward either way, why not do the right thing?
Frankly, I can't believe I need to discuss the morality of this. Is it not obvious?
And yes yes, I realise this is probably a case of Hanlon's Razor, not a moral failing, but justifying it on the grounds of there being no reward is crazy.
This case is not 'the wrong thing'. The wrong thing is selling this data to criminals, or not publishing it at all because odds are someone else is going to find it eventually.
What you're calling "the right thing" isn't zero cost. It takes a fair bit of time (spaced out over a period of months, by the way, so it's not a fire and forget it report) to report a vulnerability to microsoft and follow up with their security team. More so if your vuln is at all interesting or complex. You may have to write PoCs. Your vulnerability will be patched in 4-6 months (not exaggerating, although this will obviously be quicker if it's made the news somehow), and you'll get a minute credit in their patch tuesday notes.
So no, the morality of this is not obvious. Where is my moral obligation to effectively do charity work for a megacorp that can't be bothered to keep up with industry standards in security?
Well, I was just trying to guess their reasoning. I'd have no problem doing The Right Thing™, but I'm nowhere skilled enough to find a vulnerability anyway.
As it stands I don't think there is much harm done because it's a local vulnerability, crashing a user-mode process. Annoying, maybe, but my graphics driver has a far worse track record as far as bluescreens are concerned.
I wonder how easy it is to actually contact Microsoft on matters like this? It would probably take hours upon hours of searching convoluted corporate websites just to get an e-mail address or phone number to contact. Just slamming it on the web and posting on hacker news will take less time and is sure to reach Microsoft's attention quickly :) Sure, it's not responsible but not everyone is.
I wonder how easy it is to actually contact Microsoft on matters like this? It would probably take hours upon hours of searching convoluted corporate websites just to get an e-mail address or phone number to contact.
You could go to microsoft.com and type "report a security vulnerability" into the search box. Then click the first result.
Well that was easy. It even worked on the internationalized version in my native language, which is not common with corporate websites. But that's just the first step, anyway.
Pretty easy; you just email secure@microsoft.com (there are PGP or S/MIME keys available too) and you generally receive a response in a maximum of 48 hours. In most cases you get a reply within a few hours stating that you've passed their spamfilters, that they've done an initial overview of your report and that they will start looking into it.
Ok, tried it. This DOES NOT trigger blue screen on Windows 8 (64bit) / Visual Studio 2012. I'm pretty sure the author has some other problems in his environment.
Did you use the makefile to build it? I'm thinking that those specific compile and link flags are key to the triggering condition.
I've gotten it to crash at least three or four times on several windows 7 boxes of wildly differing configurations. No confirmed trials on a windows eight box, the bug may have been fixed there.
I also ran it on Windows 7 (64-bit). Nothing happens, although the prompt was displayed. It wasn't on Windows 8. The program doesn't do anything special. Either you're running some other version of the program, or your report is incorrect.
I think I was able to reproduce it myself. Yesterday I ran your program on one particular laptop, tried to get it to crash but it didn't. Then today when it woke up from sleep, it suddenly bluescreened. I think you may onto something here...
I hate the idea of "full disclosure." I, instead, love what this author has done. You found a bug, you're posting about it. Great. Any decent, respectable, commercial enterprise should have somebody watching sites like this, looking for posts like these. They shouldn't rely on somebody taking time away from themselves or their projects and write up a bug report. No.
We don't know the author. He may very well enjoy writing these types of articles. Filling out a form online? Maybe not so much. He also has complete freedom in writing anything he wants with no obligation of providing further proof or information. To some, that's enough motivation.
there sadly is no 'stack backtrace'. it looks like he's managed to send some message to csrss.exe that caused it to crash with an invalid memory operation.
this is bad, it might even be exploitable. even though the exploit would be in csrss, which is not kernel mode, it's still extremely important and trusted. also, untrusted low-user code could make this call to privilege escalate.
it's worth noting that thought the author states " I stumbled accross the bug inadvertently while working on something totally unrelated to security, and decided to publish my findings so that this can be fixed by Microsoft.", microsoft actually has a security team that can be found here: http://technet.microsoft.com/en-us/security/ff852094.aspx (google for "microsoft report security bug")
the bugs you report to them remain confidential until they are fixed. this way, potentially bad exploit code isn't floating around the internet for some indeterminate amount of time. like this!