Microsoft Spurned Researchers Release 0-Day 246
nk497 notes the news that a group of researchers calling themselves the Microsoft-Spurned Researcher Collective (the name is a play on Microsoft's Security Response Center) have come together to protest Microsoft's perceived heavy-handedness towards researchers who disclose security flaws. Pushed into action by the reception to the flaw disclosed by Tavis Ormandy, the group has released full details and exploit code for a previously unknown Windows local privilege escalation vulnerability. The advisory for the vulnerability, which affects Windows Vista and Windows Server 2008, contains the following manifesto: "Due to hostility toward security researchers, the most recent example being of Tavis Ormandy, a number of us from the industry (and some not from the industry) have come together to form MSRC: the Microsoft-Spurned Researcher Collective. MSRC will fully disclose vulnerability information discovered in our free time, free from retaliation against us or any inferred employer."
Not to side with Microsoft, but... (Score:5, Interesting)
This group cannot control one of these points (that Microsoft builds vulnerabilities into their OS). However, they can control the second point, by giving Microsoft advance notice and time to fix the vulnerabilities well before disclosing the vulnerabilities to the public.
It seems a bit hypocritical to me to accuse Microsoft of doing too little, too late to fix vulnerabilities, and then release unfixed vulnerabilities to the public.
Oh, great.... (Score:3, Interesting)
Just what we need: a one-stop shop for 0-day exploit code. Way to improve security, guys! Right on! Stick it to The Man! And by that, I mean the man (or woman) in the next cubical, or next door, or down the street, or....
I am all for responsible disclosure of vulnerabilities - secrecy does not equal security, and "let's not talk about it and hope nobody notices" is never an appropriate response to vulnerabilities. But responsible disclosure includes working with the vendor, giving them the full data and an opportunity to correct prior to full public disclosure.
If MS is giving researchers the cold shoulder or worse in response to vulnerabilities that are responsibly disclosed to them, that's shame on Microsoft. But to my view, jumping to public disclosure is not the appropriate response.
Re:Not to side with Microsoft, but... (Score:5, Interesting)
You forgot 3) but they don't neglect fixing holes in the activation process, even if they end up creating false alerts and block activation of legitimate IDs.
Re:Not to side with Microsoft, but... (Score:1, Interesting)
So why can't the group release all exploits they found after a specific period of time, say, 3 weeks? So whenever they have the working exploit, they email Microsoft with the exploit, and then tell them they're going to release the exploit in X weeks. That way, not only are they aware of the problem, but they cannot delay the fix forever (well they can, but they probably won't once it's out there.)
Re:Dumbdumbdumbdumbdumb (Score:3, Interesting)
Limited worldview, stupid assumptions. It's just childish to assume that MS delays action on a patch because "it hurts their feelings". It's far smarter to realize they have to manage the process in a controlled way.
Now, beauracracy means things get done slower than some people wish - that's a fair gripe. But a far smarter way to handle it would be to announce there's X issues that Microsoft is Y days behind on patching rather than detailing what the issues are, correct?
That way you'd get your point across without being destructive to the rest of us.
Re:Not to side with Microsoft, but... (Score:3, Interesting)
Irrevokeable Authenticated Delayed Publication (Score:5, Interesting)
We need an irrevokeable authenticated delayed publication mechanism: some way to put a GPG-signed document into a pipeline such that it will be published at the end of X days no matter what anyone (including the author) does. Researchers could then send their discoveries to vendors with the notation "This vulnerability will come out of the IADP system in sixty days". Browbeating them for more time would be pointless and their priority of discovery would be secure.
There are no doubt many other uses for such a system as well.
Re:So... (Score:3, Interesting)
A lot of commercial vendors treat independent researchers with contempt (how dare they find holes in our products) or as slaves (they should do the work our quality control dept should, for free)...
Of course, the folks who find a problem and then say "you have a week to fix this and then we release it into the wild" don't win their side any favours, either...
Re:Not to side with Microsoft, but... (Score:3, Interesting)
This is incredibly naive. The current methods works well, for a very specific reason. MS's real customers are businesses. The home user is an afterthought, so we might as well ignore them. Large businesses have lots of custom applications and integration and scripting. Most of this work was done in a very, very shitty way. The result is things like hard coded paths, relying on unsupported, deprecated, or undocumented functionality of libraries, all sorts of stupid, impossible to maintain bullshit. Most commercial business apps for sale are the same way. The whole thing is held together with bailing wire and happy thoughts. The result is a system that is much, much more likely to break because of patches then a normal system or home user. I have never had a patch break one my personal pc's or one of my apps, but I've seen it happen to corporate pc's all the time. The problem isn't really even Microsoft's, because shitty programmers in shitty conditions making shit can do the same in any os and will.
In the current patch system, we can test individual updates (making it easier to diagnose the cause of the problem) and once we have identified a problem patch, we can still roll out the rest. In a single cumulative version system, it's all or nothing, so if you have a game breaking patch, you get 0 patches until you have fixed the problem. In a perfect world it wouldn't matter, but in a perfect world we wouldn't need patches in the first place.
Add in the fact not all vulnerabilities are created equal, and you have a major problem. If you have two vulnerabilities, both of which cause problems for you when patched, but one is a vulnerability when you open jpgs in mspaint on the third Tuesday of the month, and the other is a remote code execution in your tcp/ip stack, you will want to prioritize the latter over the former. In a monolithic version environment, chances are most companies would be 6 months minimum behind the curve when that big bad vulnerability hit. They would have no choice but to keep plodding along (and frantically adding more programmers would most likely hurt more then it helped at that point), whereas with individual patches they could skip all the intermediate updates and deal with the first.
Re:So... (Score:3, Interesting)
What in particular about Microsoft's response to vulnerability notices do you object to? They can be a bit slow to respond sometimes - they're pretty busy - but they've never seemed either prideful or moronic to me. (Well, OK, once; but on that occasion even I had to admit it was a borderline case.)