Hacker News new | past | comments | ask | show | jobs | submit login
Google Security Team: Rebooting Responsible Disclosure (googleonlinesecurity.blogspot.com)
59 points by simonw on July 20, 2010 | hide | past | favorite | 14 comments



I don't know Chris, Eric, or Matt. But Neel, Tavis, Julien, and Michal are some of best known names in vulnerability research.

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.


"First post" and it's relevant and useful. 3 hours old and -zero- noise. This is why I love HN.

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.


Maybe I'm raving mad but doesn't 60 days seem like forever? That's tons of time for anyone to write, test and release their exploit. What takes 60 days, unless you've screwed up something completely fundamental to how your software works (in which case you'd spend far more than 60 days anyway)?


A company like Microsoft only releases new software rarely - e.g. in Microsoft cases, patches are bundled once a month. If you report a bug just before the bundle comes out, their earlier possible [1] response is ~35 days, anyway.

[1] Of course, "possible" depends on how much pressure you put on them, which is the whole argument of the Full-Disclosure camp...


Testing the patch.


And middle management meetings.


and sometimes it takes a while to understand the true nature of a bug.

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.


The words "Responsible Disclosure" are Karl-Rovian in prejudicing listeners against researchers and in favor of vendors

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.


I'm reminded of reading rain forest puppy's disclosure policy probably last decade, which I was surprised to find still online at its original home. I think I found it via alt.2600 at the time.

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.

http://www.wiretrip.net/rfp/policy.html


>0-day attacks that rely on vulnerabilities known to the vendor for a long while.

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?


An "0-day" is generally any "non-public" vulnerability. Any "0-day attack" is an any attack that uses an 0-day. If only the security researcher and vendor know of the vulnerability details, it is still an 0-day. Once the vendor releases a patch, bindiff will (usually) point very rapidly to the root cause. Thus, the details are considered public, regardless of previous disclosure details.

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.


You seem to totally ignore historical data - i.e. you install software that had 300 vulnerabilities last year, then assume it will get hacked. Restricting yourself to software with, say, at most one vulnerability in the last five years helps a lot. (Yes, I know this can be "impractical". But then you deserve what you get.)


Not really. 0-day refers to the number of days the vendor had to patch the vulnerability before it was actively being exploited. http://en.wikipedia.org/wiki/Zero-day_attack ('Bricking' is another term of late that's undergone abuse, let's not even get started on 'hacking')


"0-day" means nothing more than "unpatched". It's a silly terminology in my opinion.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: