

Google Security Team: Rebooting Responsible Disclosure - simonw
http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html

======
tptacek
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.

~~~
jjguy
"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.

~~~
makmanalp
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)?

~~~
simonw
Testing the patch.

~~~
alecco
And middle management meetings.

~~~
jjguy
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.

------
jambo
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>

------
statictype
>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?

~~~
jjguy
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.

~~~
JoachimSchipper
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.)

