Google Security Expert Finds, Publicly Discloses Windows Kernel Bug 404
hypnosec writes "Security expert Tavis Ormandy has discovered a vulnerability in the Windows kernel which, when exploited, would allow an ordinary user to obtain administrative privileges of the system. Google's security pro posted the details of the vulnerability back in May through the Full Disclosure mailing list rather than reporting it to Microsoft first. He has now gone ahead and published a working exploit. This is not the first instance where Ormandy has opted for full disclosure without first informing the vendor of the affected software."
Target Microsoft (Score:5, Interesting)
If it hadn't been Microsoft, Google may have been a bit more responsible about this, but since it makes their competitor look bad, time to forget about "do no evil".
Full disclosure and open/closed source (Score:5, Interesting)
The irony of the difference between closed source and open source is that while Ormandy has posted an exploit to this Windows bug, in the open-source world he potentially could have posted a fix too, considering he's the one who seems to understand the bug itself the best...
Re:huge conflict of interest (Score:4, Interesting)
Why does it matter? Full disclosure is the only responsible choice. That doesn't change no matter who your employer is.
Re: Fired for it? (Score:1, Interesting)
Looks like from TFA he posted both the flaw and the working exploit as himself, not as an employee. So that is at least something.
He should have known about proper disclosure practices: File a defect report, permit the company to fix the exploit, and then release the exploit to the wild at the same time the fix is released, or release it if the company fails to take action. Instead of following the protocol he put the information about the exploit both on his personal blog and on the disclosure newsgroup, with the comment that he doesn't have time to deal with it. (But apparently he does have time to blog about it.)
Was it wrong? Absolutely. There is a protocol to follow that generally protects the public and still discloses the vulnerability if it is not fixed immediately.
Should he be fired from his job as a security programmer? Maybe. He should at least get a chat with his boss and HR to explain his side.
aiding and abetting 8 computer fraud and abuse act (Score:5, Interesting)
Can google and/or this guy be prosecuted for this because releasing the working demo is basically aiding and abetting a criminal
Re:Seriously, (Score:1, Interesting)
...but we do have to support windows. We don't put our non-technical friends and family on Linux...
No. No, we do not have to support windows. Windows is not designed for us. It is designed by MS, for MS, and to maximize profits for MS. Bug fixes (might/might not get fixed) are done by MS, for MS, and to maximize profits for MS. Changes to the OS are done by MS, for MS.... well, you get the picture.
Yes, we do put non-technical friends and family on Linux. I have switched about 17 friends and family over and don't find it any more work supporting them than when they were on windows. In fact, it is easier. Try it, it works.
Win 32bit only? Meh (Score:4, Interesting)
The code is clearly targeted for x86 only, not for x64 (__declspec(naked)).
I don't have x86 PC.
On Win7x64 the code plainly crashes.
Unimpressed.
Re:Seriously, (Score:5, Interesting)
It's news that a Google employee is being a dick, since they do have a "do no evil" policy.
No, they don't. They have a "do no evil" slogan. They have been just as actively evil as everyone else for years.
Re:But not to give them a chance to correct it fir (Score:2, Interesting)
PS3 encryption== security through obscurity. (That salt doesn't need to ACTUALLY be random--each and every time-- does it? Cause, that would be a pain to implement!)
PROPER key pair generation == impossible to realistically derive the secret key from the public key and the payload, due to addition of true random salt. (Where "reasonable" means within the attacker's lifetime.) There simply is not enough information to derive all the factors to refactor the secret key. This is by design, and is considerably different from a simple password in implementation.
In other words, you are being specious, and are downplaying that the security involved with proper encryption is most definately not "if nobody looks, nobody will see!" Type security.
"Herp! He said a commonly used phrase, and I tooked exceptshun tuh dat! Hur-hur, so I calleded him an idjut and a mohron and stuffs! He coulndna poshibly know what dat phraseology thimgy rully means, like I'z does!"
Seriously, that's what you sound like when you say such dumbassery.
Re:But not to give them a chance to correct it fir (Score:4, Interesting)
I never said I believed in "unbeatable protection". That's a strawman. I basically said that "out of sight, out of mind!" Is not a proper risk mitigation practice. Most certainly NOT the same thing as professing a belief in perfect security.
Proper keypair generation attempts to make it more costly for the attacker to profit from the action of hacking, and actually demonstrates this fact for them, should they try anyway.
Shitty obscurity based half-assery fakes being strong, to detur attempts, but fails easily on inspection. Something like using a password to XOR a file, and calling it "encrypted.", or doing what sony did and reusing the sae salt over and over again, completly defeating the purpose of the salt in the process.
Relying on "don't tell anybody! We'l get to it eventually, and if you don't tell, nobody will find out!" Is bullshit, which is what typically happens with so called "responsible disclosure." I have heard of serious exploits hanging around for YEARS after being "responsibly disclosed."
I understand that you can't fix the hole instantly, and that the patch needs to be tested to make sure it doesn't poke another hole elsewhere. However, informing the people at the most risk, (customers), that they need to take some mitigating actions to reduce the threat, and to watch for signs of exploit until the patch is ready is what is the responsible thing for the software vendor to do. NOT hide the exploit and try to forget about it, while less scrupulous crackers silently use it in combination with other exploits to commit fraud, steal company prividleged information, steal user persona data, build botnets, and worse, while pretending that "it won't happen, because nobody squealed!"
Re: But not to give them a chance to correct it fi (Score:5, Interesting)
The nonsequitor there, is in asserting that because the whitehat hasn't disclosed his findings, that others haven't also independently found the hole, and been more mum about it.
Which is more profitable for a person who makes their living by stealing company secrets, laundering money through wire fraud, or selling stolen identity information?
Using an exploit that has been publicly discosed, and thus, everyone is super paranoid about it, and actively trying to plug it-- OR-- a nice little treasure trove of privately discovered exploits that aren't public knowledge that you can quiety switch to once the hole you are currently using gets discovered?
"Saving face" for the company fascilitates the real blackhats by keeping admins and users ignorant of the threat.
All public disclosure does is make real blackhat attackers silently move to their next vector, and cause a spike in script kid activities. (And of course, make the software vendor look bad.)