News Stay informed about the latest enterprise technology news and product updates.

Google Project Zero changes fuel new vulnerability disclosures debate

Google's Project Zero has added more leeway to its vulnerability disclosure policy, but industry observers are split on whether 90 days is enough time to fix software flaws, or not enough time to manage a sensitive, resource-intensive process.

Google's decision to change its controversial vulnerability disclosure policy has sparked a debate in the information...

security community over just how much time software vendors need to fix a flaw before it is made public.

Google's Project Zero zero-day exploit-finding unit came under fire recently following its exposure of Microsoft bugs immediately after the expiration of the self-imposed 90-day deadline it grants software vendors to fix flaws. Microsoft argued that patches were overdue by only a few days, and that negotiations with Google about extending the deadline were futile.

If you go into discussion about disclosure without a deadline, then you're not going to get anywhere.
Art Manionvulnerability analyst at CERT

After facing criticism for what some perceived to be an overly rigid policy, Google has opted for a more flexible approach, instituting an optional two-week extension for vendors that pledge they are ostensibly on the brink of making patches available. The new policy, announced on the Project Zero blog, also provides CVEs and takes into account weekends and holidays, allowing for the expiration to come on the next normal workday.

"Google has certainly shown that they were being very strict with their 90-day deadline," said Art Manion, a vulnerability analyst with the Computer Emergency Response Team (CERT) at Carnegie Mellon University's Software Engineering Institute in Pittsburgh. "It seems that they're looking for a number that they can be very strict with, but that actually fits what the response times look like."

But Google, which has also disclosed flaws in Apple Inc.'s software, stood by its claim that this 90-day period prior to exposure should be enough time to work out a patch for most vulnerabilities.

"To see how things are going, we crunched some data on Project Zero's disclosures to date," the Project Zero team wrote in a blog post. "For example, the Adobe Flash team probably has the largest install base and number of build combinations of any of the products we've researched so far. To date, they have fixed 37 Project Zero vulnerabilities [or 100%] within the 90-day deadline."

Adobe Systems Inc. declined comment. Google was unavailable for comment.

"More generally," Google's blog post read, "of 154 Project Zero bugs fixed so far, 85% were fixed within 90 days. Restrict this to the 73 issues filed and fixed after Oct. 1, 2014, and 95% were fixed within 90 days. Furthermore, recent well-discussed deadline misses [Issues 123, 135 and 136] were typically fixed very quickly after 90 days."

And Google is not the only company with a strict deadline for revealing vulnerabilities: Yahoo Inc. also has a 90-day deadline policy for vulnerability disclosures, while CERT has a policy to reveal bugs after just 45 days from when the vendor is notified, though Manion admitted that policy is flexible.

"We've taken a slightly different approach," Manion said. "We have a 45-day deadline; however, in practice, if we are working with a vendor who's being responsive and fixing the issue, and there is no external threat … we're quite willing to negotiate a longer deadline than 45 days."

While Project Zero's deadline was twice as long as CERT's, Microsoft took issue with Google's inflexibility and unwillingness to negotiate on the deadline.

"When finders release proof-of-concept exploit code, or other information publically before a solution is in place, the risk of attacks against customers goes up," Chris Betz, senior director of Microsoft Security Response Center, said in a statement to SearchSecurity. "While it is positive to see aspects of disclosure practices adjust, we disagree with arbitrary deadlines because each security issue is unique and end-to-end update development and testing time varies."

Manion said it's not necessarily true that Microsoft's vast resources allow for faster patching, since a larger company would have to work through more applications and code in its regression testing.

"An open source project has some more flexibility: First of all, you might be willing to take the chance that you do break something, you'll just fix it again in 48 hours," Manion said. "A large commercial vendor doesn't really have that luxury … fixing a complicated vulnerability in Windows, regression testing it, and not breaking something else -- that's a nontrivial investment."

Still, Manion said that without a predetermined amount of time, vendors are likely to drag their feet on patches. The threat of exposure guarantees a timely solution to a flaw that might put customers at risk.

"What I've found is that if you go into a discussion about disclosure without a deadline, then you're not going to get anywhere," Manion said. "You have to have at least a line in the sand or some starting point for this discussion."

However, there are others who have criticized Google for its Project Zero disclosures and claim the exposure of Microsoft and Apple software flaws is an attack on the competition.

Others have claimed Google's Project Zero disclosure policy is hypocritical, especially in light of the company's controversial patching policy for Android (Google recently announced it will no longer patch WebView vulnerabilities in older versions of Android, which some say leaves millions of devices at risk).

Tod Beardsley, software engineering manager at Rapid7 LLC, a Boston-based security software vendor, chastised Google for not patching WebView vulnerabilities in its Jelly Bean Android OS. That version of Android is used by nearly 45% of active Android devices, according to the most recent data on the Android developers' website. KitKat, the next model, holds 39.7% of the market. The newest version, Lollipop, is at 1.6% distribution.

"Technically, Google seems to be off the hook for patching WebView bugs prior to Android 4.4 [KitKat] because Google believes these bugs to exist only in 'legacy' installations of Android," Beardsley said. "If Google has bugs on Windows XP, for example, I wouldn't expect them to hold Microsoft to a 90-day disclosure timeline, since XP is similarly end-of-life. … Disclosing bugs on unmaintained software without prior disclosure to the vendor is somewhat typical."

Beardsley added that it is disingenuous to call Android Jelly Bean a legacy product, "since it's not that old, is in use by literally hundreds of millions of people, and is for sale in stores today."

Manion said the overall directive for disclosures should be to minimize the potential harm of the disclosure, yet admitted that the best way to accomplish that goal changes on a case-by-case basis.

"We want to minimize harm to everyone," Manion said. "That includes the vendor. That includes the researcher. That includes the customers and the users and the Internet."

Next Steps

Find out how Google created its own vulnerability research group with Project Zero.

Dig Deeper on Microsoft Patch Tuesday and patch management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Is 90 days enough time for software vendors to address vulnerabilities?
Cancel
Insufficient testing and lack of proper audit trails are the most common flaws in vendor software. There are three concepts involved when it comes to the attack of information whenever there is a flaw. The first is presence of an attack surface, the ability of an attacker to access the flaw, and f the ability of the attacker to exploit the flaw. Normally, it takes about 45 days for a vendor to rectify the flaw.
Cancel
I've heard a lot of debate around this.  The reality is the technical world advances very, very rapidly.   Even if google does NOT release this information after 90 days, that doesn't mean its not known by a select group of malicious parties and being actively exploited.

Ideally no exploits would ever be found, and if they were they'd be fixed the day they were found.  Unfortunately most dev teams don't operate that way, and even if they tried, it likely takes a detailed investigation to understand any given exploit before it can be mitigated.  

Therefore, I would suggest, that there are some companies that could use some 'added' pressure to get these sorts of things fixed faster.  However, who is Google to decide that 90 days is enough?

Furthermore, to set a deadline has the same effect as many metrics.  They lose their context, and can be misapplied.  In this case, can you imagine it being applied to bugs of different severity level.  I do believe more companies need to take security issues seriously, but I'm not sure 90 days is the way to achieve it.
Cancel
Let's put that in the context.
Is 90 days enough time to address exploits in self-driving cars? Heck, the seasons may change till the patch arrives.
Is 90 days enough time to address vulnerabilities in online tax filing system? Heck, the whole economy might collapse in that timeframe!
Cancel
Is 90 days tough? Yes. That said, it's reasonable for enterprises that focus on resolving issues fast. Companies need to be pushing their time-to-patch lower.
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close