Questioning Google's disclosure timeline motivations
by Gunter Ollmann - CTO at IOActive - Friday, 31 May 2013.
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.

Spotlight

How security analytics help identify and manage breaches

Posted on 30 July 2014.  |  Steve Dodson, CTO at Prelert, illustrates the importance of security analytics in today's complex security architectures, talks about the most significant challenges involved in getting usable information from massive data sets, and much more.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  

DON'T
MISS

Thu, Jul 31st
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //