alex_aldo - Fotolia
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.
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.
— Chris Marriott (@chrismarriott) February 17, 2015
— Digital Corps (@DigitalCorps) February 18, 2015
— jonathanross (@jonathanross) January 20, 2015
Apparently Google have deicided NOT to be that guy, Project Zero deadline extended http://t.co/YYajPjhmG8
— jonathanross (@jonathanross) February 17, 2015
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."
Find out how Google created its own vulnerability research group with Project Zero.