Questioning Google’s disclosure timeline motivations

The presence of 0-day vulnerability exploitation is often a real and considerable threat to the Internet – particularly when very popular consumer-level software is the target.

I think the stance of Chris Evans and Drew Hintz over at Google on a 60‑day turnaround of vulnerability fixes from discovery, and a 7-day turnaround of fixes for actively exploited unpatched vulnerabilities, is rather naive and devoid of commercial reality.

As a web services company it is much easier for Google to develop and roll out fixes promptly – but for 95+% of the rest of the world’s software development companies making thick-client, server and device-specific software this is unrealistic.

Statements like these from Google clearly serve their business objectives. As predominantly a web services company with many of the world’s best software engineers and researchers working for them. One could argue that Google’s applications and software should already be impervious to vulnerabilities (i.e. they should have discovered them themselves through internal QA processes) – rather than relying upon external researchers and bug hunters stumbling over them.

With that in mind, I’d be more inclined to say that Google (and any web-based service provider – e.g. Salesforce.com, etc.) should be fixing disclosed vulnerabilities within 48 hours of knowledge of them and, in the case of 0-day’s the turnaround should be within 12 hours. While the 12-hour turnaround may not be the “final” fix – something could be rapidly put in place to prevent exploitation at the very least.

From an IOActive perspective, when I think of the vulnerabilities we uncover in ICS, medical devices and enterprise-level solutions software, on a daily basis I’m cognizant of the effort that goes on behind the scenes as these manufacturers drive through sophisticated QA processes to ensure their fixes work for all possible customer configurations.

Unlike a flaw in Gmail which allows someone to conduct a cross-site scripting attack – in many cases we’re talking about vulnerabilities that have national security implications and huge monetary and safety implications.

I’d hope that Google’s pursuit of shorter patch release timeframes are genuinely to make the Internet a safer place – but I fear that this latest position may be more of a competitive business statement, rather than a naive understanding of non-web service development cycles.

We’d all dearly love vulnerabilities to be patched much more quickly – and there is a growing need to do so given the evolving state of the criminal exploit ecosystem – but the pre-emptive release of vulnerability details before a patch or fix is ready cannot realistically serve the vulnerable targets best interests. Sure – promote workarounds for 0-days, but bear in mind that there are other realities in the way vulnerable organizations must respond to the threat.

If anything, I would hope that Google could step up to the plate more aggressively and block the malicious content and/or remove it from search results when 0-days are under way. That would be much more productive and have a meaningful impact to the vulnerable users/targets.