Software Flaw Disclosure Deadlines Raise Vendor-Researcher Tensions

By Robert Lemos  |  Posted 2015-01-29 Print this article Print
Flaw Disclosure

Google's Project Zero puts a time limit on patching software flaws, which irks software vendors. But firm deadlines can improve security.

In early January, Google's Project Zero—a 6-month-old effort to hunt for bugs in popular software—released, for the second time, information on a vulnerability in Microsoft software before the software giant had patched the issue. Not two weeks later, Google took the same action for security issues in Apple's products.

Google has argued that holding every software vendor to a 90-day deadline will improve security. But by exposing security issues in products of two of the largest software companies, Project Zero has become the latest focal point in the debate between researchers, who typically favor disclosure of their efforts, and software vendors, who would rather that vulnerabilities remain hidden.

When Google released information about the flaws in Microsoft software on Jan. 11, two days before the software giant had scheduled to patch the issue, Chris Betz, senior director of Microsoft's Security Response Center (MSRC), took to the company's blog to criticize Google's tactics.

"Although following through keeps to Google's announced timeline for disclosure, the decision feels less like principles and more like a 'gotcha', with customers the ones who may suffer as a result," Betz wrote. "What's right for Google is not always right for customers. We urge Google to make protection of customers our collective primary goal."

The debate over how best to disclose vulnerabilities has always been contentious, seesawing over the past two decades, with software users typically left feeling vulnerable in the middle.

In 2000, a security researcher known as "Rain Forest Puppy" released a policy document that established the roles and responsibilities of the actors in the vulnerability disclosure process. The document also gave software vendors ammunition against researchers who disclosed full details of vulnerabilities without giving adequate time to patch.

Nine years later, however, as Microsoft and other software vendors put more pressure on researchers to "responsibly" disclose vulnerabilities by coordinating with software developers, a group of three well-known researchers started a movement known as "No More Free Bugs," highlighting that researchers were increasingly asked to help fix vendors' software with no compensation.

Third-party bounty programs, such as the Zero-Day Initiative, made paying for vulnerabilities more acceptable.

The latest question in the debate is whether deadlines, and increasingly shorter ones, help security in the long run, forcing vendors to be more responsive and to invest in an agile patching infrastructure. The Zero-Day Initiative argues that it does and has shortened its general deadline for vendors to 120 days, from 180 days, Brian Gorenc, manager of vulnerability research for HP Security Research, told eWEEK.

"We applaud programs like Project Zero," he said. "Deadlines provide these vendors with the extra push to get these vulnerabilities fixed."

A study of nine years of ZDI data showed that the vendors have quickly adapted to deadlines by producing patches more quickly, Gorenc said. The data convinced HP to shorten its own deadline to 120 days. In the next five years, the program will likely shrink the deadline again.

Yet, Microsoft argues that faster is not always better. The software maker, which has had its own contentious relationship with the research community, coined the term "responsible disclosure" to describe researchers who work with the vendors. The company eventually settled on calling their approach "coordinated disclosure" and does not support the full disclosure of vulnerability details.

"Those in favor of full, public disclosure believe that this method pushes software vendors to fix vulnerabilities more quickly and makes customers develop and take actions to protect themselves—we disagree," Betz wrote. "Releasing information absent context or a stated path to further protections unduly pressures an already complicated technical environment."

Other researchers point out that even Google would have problems meeting its own deadlines.

"As far as we can see, Google's high horse about 90 days being enough for a 'broadly available patch' isn't really borne out in its own Android ecosystem," Paul Ducklin, head of technology for antivirus firm Sophos, stated in a blog post on the issue.

"Security patches may make it into Google's Android Open Source Project in just a few days, which sort-of makes them 'broadly available,' yet those same patches often can't be deployed by Android users for weeks, months, years, perhaps even ever."


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel