As regular readers will know, I’ve been a little critical of Google of late when it comes to their disclosure of vulnerabilities in other people’s software.
In the past few weeks, Google has not only disclosed publicly a number of zero-day vulnerabilities in Microsoft Windows and OS X, but has also released proof-of-concept code demonstrating how to exploit them.
The obvious danger is that malicious hackers could use these disclosures as a blueprint for attacks.
To make things worse, in some cases Google’s security researchers knew that the bugs were already scheduled to be patched within a matter of days – and yet chose to tell the world how clever they were anyway, and potentially put many users at risk.
This isn’t new behaviour by Google’s Project Zero security researchers. Way back in 2010, Google’s Tavis Ormandy publicly released details of a zero-day vulnerability in Microsoft’s code, only for online criminals to exploit it to spread a Trojan horse days later.
What’s different is that Google announced last year that it would only be giving software vendors 90 days to fix their bugs – after which, the technology giant felt, it was acceptable to make them public for the world to know about.
That is despite, for instance, Microsoft begging Google to hold off releasing details of security holes when patches were not only in the works, but about to be imminently released.
You could argue that that wasn’t terribly friendly behaviour by Google.
Perhaps smarting from the negative reaction from many commentators, Google has now said it is adjusting its policy… a little bit.
We have taken on board some great debate and external feedback around some of the corner cases for disclosure deadlines. We have improved the policy in the following ways:
* Weekends and holidays. If a deadline is due to expire on a weekend or US public holiday, the deadline will be moved to the next normal work day.
* Grace period. We now have a 14-day grace period. If a 90-day deadline will expire but a vendor lets us know before the deadline that a patch is scheduled for release on a specific day within 14 days following the deadline, the public disclosure will be delayed until the availability of the patch. Public disclosure of an unpatched issue now only occurs if a deadline will be significantly missed (2 weeks+).
* Assignment of CVEs. CVEs are an industry standard for uniquely identifying vulnerabilities. To avoid confusion, it’s important that the first public mention of a vulnerability should include a CVE. For vulnerabilities that go past deadline, we’ll ensure that a CVE has been pre-assigned.
As always, we reserve the right to bring deadlines forwards or backwards based on extreme circumstances.
Well, that’s a bit better. And the 14-days grace period should help avoid the scenario of Google announcing software flaws a day or two before Microsoft is due to fix them in a Patch Tuesday update.
But I’m still concerned that Google isn’t acting in the best interest of most internet users with its full disclosure policy and releasing of proof-of-concept code.
Surely to pressure a software vendor into fixing a bug, it doesn’t have to give the mechanisms for exploiting a vulnerability into the hands of those who might exploit them for malicious purposes?
What Google Project Zero team has never satisfactorily explained is what would be so wrong with them privately demonstrating any unpatched vulnerability to a member of the technology press? The media should always be the preferred mechanism for getting a software bug fixed if a vendor is being too slow, rather than putting members of the internet community at risk.
Found this article interesting? Follow Graham Cluley on Twitter to read more of the exclusive content we post.