Google Security Team: Rebooting Responsible Disclosure
googleonlinesecurity.blogspot.com
googleonlinesecurity.blogspot.com
Neel used to run vulnerability research for ISS, the second vulnerability lab ever started (;]) and the largest, and is universally acknowledged as one of the best in the field. Tavis Ormandy you all know from the recent publicity, but I've been paying attention to him ever since he wrote a paper on busting hypervisors by fuzzing their simulated device interfaces. Julien wrote metasm and a few hunred other things for Metasploit. Michal is lcamtuf, author of p0f (one of the most famous Unix network security tools of all time) and a vuln researcher since the '90s.
It is remarkable that Google employs these people, and just as remarkable that these are the people Google chooses as spokespeople for their software security policies. An extremely clueful move on G's part.
It's also remarkable that it's taken until 2010 for it to hit the mainstream that the words "Responsible Disclosure" are Karl-Rovian in prejudicing listeners against researchers and in favor of vendors.
You avoided commenting on the substance of their position, though. From your role as a security researcher, I suspect you're in the google camp. I'm close enough to a security researcher to agree, too -- but I also know my perspective is fairly clouded. How will the vendors respond?
I suspect Microsoft will be reasonable, although they'll pushback at the proposed default window of 60 days. Microsoft is in the singularly unique position of having a reasonably agile security team, matrixed across the product teams. The majority of other vendors (Adobe?) are still struggling to put even basic processes into place; they won't have a choice but to push back with vigor and fill the discussion with FUD.
I second your "congrats google" -- it is a clueful corporate move and inspires confidence in their corporate bureaucracy. But I'm skeptical on it's effectiveness.
and sometimes the "right way" to fix something is unclear.
and sometimes the fix straddles multiple components, managed by different teams.
and sometimes "that guy" who knows the subsystem is off at Disneyland for two weeks.
60 days can pass very quickly, especially as the project and vulnerability complexity grows. It's a short enough window to put the vendor under time pressures from day one.
[1] Of course, "possible" depends on how much pressure you put on them, which is the whole argument of the Full-Disclosure camp...
Yeah, the phrasing totally puts the onus on the reporter. I felt really sorry for an HNer who posted a while back ( http://news.ycombinator.com/item?id=1445794 ) basically "I am this vendor's customer, I reported this hole months ago, it is actually affecting me, what do I do?".
If 60 days or whatever became an industry standard (or at least the common expectation) then people would hopefully feel better about taking the next step if they are being stonewalled.
Now it reads as harsh and rigid, but at the time, I think the hackers & crackers & researchers I was interested in were doing full, immediate disclosure.
Could someone clarify the meaning of a 0-day attack? From what I understood, it's an attack that happens on the day it was discovered - with, often times, the discovery happening soley because of the attack.
If the vulnerability was known to the vendor for a long while is it still a 0-day attack?
These capture the imagination and frustrate system administrators because 0-day -- due to their unknown nature and nearly infinite possibility -- cannot be simply "fixed."
This has been a core frustration of mine in the network defense community for years: our procedures are too narrowly focused on protection -- keeping bad guys out. This is necessary but insufficient. We must assume bad guys will get in and focus on how we detect, respond and recover. Unfortunately, these last three steps get ignored too often -- resulting in bad guys never being detected once they're inside the gates.