Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

11:33 AM
Connect Directly

Microsoft Launches 'Coordinated' Vulnerability Disclosure Program

Microsoft abandons controversial 'responsible disclosure' term, supporting public disclosure of unpatched bug details when attacks hit

Microsoft today revealed a new, modified approach to how it works with security researchers and handles vulnerability disclosures, including working with researchers to publicly release vulnerability details of a zero-day flaw when attacks are under way.

In an interview with Dark Reading, Mike Reavey, director of Microsoft Security Response Center, said Microsoft is now promoting "coordinated vulnerability disclosure" (CVD) and moving toward working more closely with researchers in coordinating the release of details on new, unpatched bugs. Reavey says the term "responsible disclosure" had become too emotionally charged and it was time for a shift in philosophy.

"This is not a drastic departure from what we're already doing, but we think it's important," Reavey says. "The two changes here are talking about how responsibility extends beyond disclosure -- where [researchers and vendors] are working together to minimize the risk [to users]," he says. "And if there attacks in the wild, we are working to coordinate [disclosure] even if a fix isn't ready."

Reavey says Microsoft's shift in philosophy came, in part, out of feedback it has received from the security community over the emotionally charged term "responsible disclosure."

"It makes sense to talk about vulnerability disclosure for what it really is and what works. So we're making a call to shift the way we talk about it ... to coordinated vulnerability disclosure," says Reavey, who posted a blog with this announcement.

If active attacks are exploiting an unpatched flaw, he says, then it makes sense to alert users about the bug. "We're making sure that we can coordinate the release of vulnerability details with a fix that's broadly available for all customers," Reavey says. "In an active attack, it's OK to release vulnerability details. This is a clear call to action for customers to know what to do. We did that recently with the Help Center issue and with the Shortcut files issue [in Windows]."

But Microsoft hasn't changed its stance against full disclosure, where a bug finder releases details of a flaw without the vendor getting a shot at patching it first. Reavey says Microsoft is, however, willing to work with researchers who go that route to work on a fix for the flaws they reveal publicly. "If someone has the mindset that they want to disclose fully [a vulnerability], we disagree because it's not best way to protect customers. But we still work with them," he says.

The software giant has been under pressure from security researchers who disagree with what had been Microsoft's traditional stance on responsible disclosure, where a bug finder hands over the discovery to the affected vendor, which then handles the fixes on its own timetable. A series of recent zero-day disclosures, including one from Google researcher Tavis Ormandy and then from a group of hackers calling themselves "Microsoft-Spurned Researcher Collective," brought the issue to fore: Microsoft took issue with Ormandy's handling of the disclosure, in which he reported the bug to Microsoft on June 5 and then went public with it four days later -- before the vendor was able to fix it.

Meanwhile, late yesterday Ormandy and other Google researchers issued a plea for speeding up vendors' patch turnaround times. "Whilst every bug is unique, we would suggest that 60 days is a reasonable upper bound for a genuinely critical issue in widely deployed software. This time scale is only meant to apply to critical issues," they blogged.

The Googlers contend it can be "irresponsible" for a flaw to remain unfixed over a long period of time -- sometimes years. The researchers for the search engine giant say from now on, they will set a disclosure deadline on any serious bug they report, and if the vendor doesn't fix it within that time frame, then they will publish an analysis of the bug as well as any workarounds. Researchers will also be able to set "an aggressive disclosure deadline where evidence exists that blackhats already have knowledge of a given bug," they said. "We would invite other researchers to join us in using the proposed disclosure deadlines to drive faster security response efforts."

Setting patch deadlines is something Microsoft doesn't support. Microsoft contends that patching is a delicate balance between quality and timeliness; it goes through an involved testing process before issuing a patch.

"The real reason we don't have a set deadline for fixing security issues is that there's not a one-size-fits-all for Microsoft or the industry," Reavey said in the interview. "We want to make sure when we put out an update for customers, it works."

And some patches take longer to fix than others due to the complexity of the flaw and how it could affect other software products, he says. "The ATL [Active Template Libraries] vulnerability took over a year to get fixed. It was a vulnerability that affected 89 Microsoft products and 37 third-party, non-Microsoft products," Reavey says. "The vulnerability itself was fairly straightforward, but when it involves multiple products, it took some time to get that out and fixed."

Meanwhile, the vulnerability reporting process to Microsoft basically stays the same with CVD, according to Reavey, including assigning a Microsoft security representative to work with the researcher throughout the life cycle of the bug and patching, for example.

The reality is no one party can tackle bugs and exploits by the bad guys, Reavey says. "With this complex landscape we have with cybercrime, no one vendor or person can solve this problem by themselves. The responsibility is to coordinate and get together as a community," he says.

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

Kelly Jackson Higgins is the Executive Editor of Dark Reading. 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
Newest First  |  Oldest First  |  Threaded View
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
PUBLISHED: 2021-01-15
Docker Desktop Community before on macOS mishandles certificate checking, leading to local privilege escalation.
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, AttachmentUploadServlet also saves user controlled data (`request.getInputStream()`) to a user specified location (`request.getHeader("File-Name")`). This issue may lead to arbitrary file upload which can be used to u...
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, the REST UserResource endpoint performs a security check to make sure that only administrators can list user details. However for the `/users/` endpoint there are no security checks enforced so it is possible to retrieve ar...