Risk
7/21/2010
06:45 PM
Connect Directly
LinkedIn
Twitter
Google+
RSS
E-Mail
50%
50%

Google Seeks Redefinition Of 'Responsible Disclosure'

Arguing that speedy software fixes enhance user security, Google wants the security community to change vulnerability disclosure practices.

Google's security team on Tuesday asked the computer security community to reconsider the meaning of responsible disclosure and to adopt a more rigorous approach in order to respond more quickly to vulnerabilities.

Responsible disclosure, explain Chris Evans, Eric Grosse, Neel Mehta, Matt Moore, Tavis Ormandy, Julien Tinnes, and Michal Zalewski in a blog post, involves notifying software vendors about vulnerabilities privately, to provide time to patch vulnerable products before the flaws are made public.

It's an approach preferred by large software makers such as Apple, Microsoft, and Oracle. But Google's security researchers argue it's no longer working.

"We’ve seen an increase in vendors invoking the principles of 'responsible' disclosure to delay fixing vulnerabilities indefinitely, sometimes for years; in that timeframe, these flaws are often rediscovered and used by rogue parties using the same tools and methodologies used by ethical researchers," they contend.

An example of industry foot-dragging could be seen in January, when Ormandy disclosed details about a vulnerability in the Windows Virtual DOS Machine (VDM) subsystem. Microsoft had been aware of the flaw, which had existed for 17 years, for at least six months and had not fixed it when Ormandy published details of the problem. He notified Microsoft of the bug on June 12, 2009 and he says that Microsoft acknowledged the notification 10 days later.

Ormandy was also behind the publication of a zero-day vulnerability in the Windows Help and Support Center function in Windows XP and Windows Server 2003.

Negative response to that disclosure prompted an unknown number of security researchers to strike back by forming a group dedicated to full disclosure, which involves letting everyone know about a vulnerability at the same time.

"Due to hostility toward security researchers, the most recent example being of Tavis Ormandy, a number of us from the industry (and some not from the industry) have come together to form MSRC: the Microsoft-Spurned Researcher Collective," the group declared in a security advisory published earlier this month. "MSRC will fully disclose vulnerability information discovered in our free time, free from retaliation against us or any inferred employer."

For Google's security team, the language of the debate -- specifically the use of the term "responsible" -- needs to change. Insisting that private disclosure of vulnerabilities is responsible puts those advocating a different approach at a disadvantage by implying that any alternative is irresponsible, they argue.

What's more, they argue that it can be irresponsible to leave flaws unfixed for long periods of time. They suggest that critical bugs in widely deployed software should be fixed in no more than 60 days.

"We would invite other researchers to join us in using the proposed disclosure deadlines to drive faster security response efforts," Google's security team concludes. "Creating pressure towards more reasonably-timed fixes will result in smaller windows of opportunity for blackhats to abuse vulnerabilities."

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-4293
Published: 2015-07-30
The packet-reassembly implementation in Cisco IOS XE 3.13S and earlier allows remote attackers to cause a denial of service (CPU consumption or packet loss) via fragmented (1) IPv4 or (2) IPv6 packets that trigger ATTN-3-SYNC_TIMEOUT errors after reassembly failures, aka Bug ID CSCuo37957.

CVE-2014-7912
Published: 2015-07-29
The get_option function in dhcp.c in dhcpcd before 6.2.0, as used in dhcpcd 5.x in Android before 5.1 and other products, does not validate the relationship between length fields and the amount of data, which allows remote DHCP servers to execute arbitrary code or cause a denial of service (memory c...

CVE-2014-7913
Published: 2015-07-29
The print_option function in dhcp-common.c in dhcpcd through 6.9.1, as used in dhcp.c in dhcpcd 5.x in Android before 5.1 and other products, misinterprets the return value of the snprintf function, which allows remote DHCP servers to execute arbitrary code or cause a denial of service (memory corru...

CVE-2015-2977
Published: 2015-07-29
Webservice-DIC yoyaku_v41 allows remote attackers to create arbitrary files, and consequently execute arbitrary code, via unspecified vectors.

CVE-2015-2978
Published: 2015-07-29
Webservice-DIC yoyaku_v41 allows remote attackers to bypass authentication and complete a conference-room reservation via unspecified vectors, as demonstrated by an "unintentional reservation."

Dark Reading Radio
Archived Dark Reading Radio
What’s the future of the venerable firewall? We’ve invited two security industry leaders to make their case: Join us and bring your questions and opinions!