Tuesday, July 20, 2010

Fixing responsible disclosure

Today I had the pleasure to post:

http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html

It is co-signed by some of my awesome fellow engineers who personally believe in what is written.

Recent discussions and debates have shown that "responsible disclosure" is broken. It is badly named and ill-defined. Possibly the worst problem with responsible disclosure is that is permits known critical vulnerabilities to go unfixed for months or even years. As many commentators have pointed out, that is hardly "responsible". We've also seen what happens when we go down that route.

The simple proposed fix is to use reasonable deadlines to encourage things in the right direction. 60 days for critical issues. ("critical" in the genuine unsandboxed & arbitrary code execution sense, not "critical" just because some news article or researcher is overstating things).

Speaking personally about my work on securing the Chromium browser: I'd be mortified if I learned of a SecSeverity-Critical bug and it took me over 60 days to protect my users from it. It's not always possible to move this fast, but for one of the few critical bugs I found, the timeline shows it was not only fixed but also installed across the user base in about 6 days.

Related reading:

2 comments:

c said...

Cool. Does that means that if I report an Android vuln that it will be patched in an OTA on all affected phones within 60 days?

Chris Evans said...

@c: I don't research mobile devices, but I can draw some parallels with open source bugs I've found and reported in e.g. libpng. I'd expect the libpng software team to have a fix within 60 days, but they don't have control over all the places that have decided to embed libpng in software or even devices.