Vulnerabilities / Threats

5/29/2013
06:29 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Google Sets New 'Aggressive' 7-Day Deadline For Vendors To Reveal Or Fix Zero-Day Bugs Under Attack

New policy narrows window for software vendors' public response to zero-day bugs discovered by Google researchers

Google today put the squeeze on software vendors with a new policy for vulnerability disclosure that allows its researchers to provide details on zero-day bugs they find within seven days if the affected vendor hasn't provided an advisory or a patch.

Chris Evans and Drew Hintz, security engineers with Google, made the announcement in a blog post, noting that Google's researchers recently discovered attacks using a zero-day in another unnamed vendor's software. "We recently discovered that attackers are actively targeting a previously unknown and unpatched vulnerability in software belonging to another company. This isn’t an isolated incident -- on a semi-regular basis, Google security researchers uncover real-world exploitation of publicly unknown (“zero-day”) vulnerabilities. We always report these cases to the affected vendor immediately, and we work closely with them to drive the issue to resolution," the Googlers said in their post.

Vulnerability disclosure long has been a hot button topic, with Google over the past few years pushing hard on vendors to more quickly warn users and fix new flaws, and software giant Microsoft standing by its policy that vulnerability fixes should not be assigned deadlines. Microsoft contends that patching is a delicate balance between quality and timeliness that can't be put on a specific deadline.

But Google is now dramatically narrowing the patch window for the most dangerous zero-day bugs it discovers and get used in attacks in the wild.

"Our standing recommendation is that companies should fix critical vulnerabilities within 60 days -- or, if a fix is not possible, they should notify the public about the risk and offer workarounds. We encourage researchers to publish their findings if reported issues will take longer to patch. Based on our experience, however, we believe that more urgent action -- within 7 days -- is appropriate for critical vulnerabilities under active exploitation," the Google researchers say. "The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised."

They acknowledge that a one-week turnaround is tight and may not work for some vendors. And Google itself will follow the same timeline in fixing its own bugs, they say.

"Seven days is an aggressive timeline and may be too short for some vendors to update their products, but it should be enough time to publish advice about possible mitigations, such as temporarily disabling a service, restricting access, or contacting the vendor for more information," they say. "As a result, after 7 days have elapsed without a patch or advisory, we will support researchers making details available so that users can take steps to protect themselves. By holding ourselves to the same standard, we hope to improve both the state of web security and the coordination of vulnerability management."

Google security engineers in 2010 called it "irresponsible" for a software bug to remain unfixed over long periods of time -- sometimes years. They announced back then that they would set disclosure deadlines for serious bugs they found, and if the affected vendor didn't fix the bug by that date, Google would publish an analysis of it and any workarounds.

Today the engineers say it's becoming even more urgent to fix bad bugs faster. "Often, we find that zero-day vulnerabilities are used to target a limited subset of people. In many cases, this targeting actually makes the attack more serious than a broader attack, and more urgent to resolve quickly. Political activists are frequent targets, and the consequences of being compromised can have real safety implications in parts of the world," the said in their post.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Diversity: It's About Inclusion
Kelly Jackson Higgins, Executive Editor at Dark Reading,  4/25/2018
Coviello: Modern Security Threats are 'Less About the Techniques'
Kelly Sheridan, Staff Editor, Dark Reading,  4/24/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.