Posted by Synopsys Editorial Team on Friday, December 1st, 2017
The definition of responsible vulnerability disclosure varies based on who you ask. Tech goliath Microsoft has openly disagreed with Google on this very topic, as outlined by The Verge.
In the vulnerability management industry, discretion is key. Because we’re continuously handling vulnerabilities that can be used maliciously by black hats, there are widespread implications and risks that come with hastily disclosing the latest findings, especially when they’re unknown vulnerabilities.
What exactly is an unknown vulnerability? In short, vulnerabilities fall into two categories:
Notice that each definition contains two conditions coupled by an “and.” It’s this conjunction that the Google-Microsoft debate revolves around.
Figure 1: Differences between known and unknown vulnerabilities
For the safety and security of the public, responsible disclosure best practices recommend that the vulnerability finder first notify the vendor privately. The finder must provide the vendor with adequate time not only to develop fixes and/or patches but also to push out software updates. Once fixes, patches, and updates have been proliferated throughout the software supply chain, only then should the finder publicly disclose the findings.
A coordinated disclosure process between the vendor and vulnerability finder is crucial for preventing attacks. When information on how to exploit software is available, but information on how users can protect themselves is not, there can be dire consequences that affect not only vendors but also their customers. Remember, in the Internet of Things (IoT) era we live in, attacks can be conducted remotely—meaning from anywhere in the world—and can affect millions of users at once.
The reality, though, is that pushing a software update through the supply chain takes substantial time and effort. We at Synopsys have experienced this firsthand. When the Synopsys Fuzz Testing team ran Defensics against the Linux kernel in an internally organized hackathon, they stumbled on three critical vulnerabilities. We found the vulnerabilities in March 2017, and we publicly disclosed in May 2017. Although it may seem like it’s just a little over a month between discovery and disclosure, we had a team dedicated to this finding for roughly 6 months—from discovering the issue, to working with vendors to reproduce our finding, to working with information-sharing organizations, to public disclosure. The time gap we experienced between discovery and disclosure is fairly short compared to most.
Some question whether a large time gap between discovery and disclosure is fostered by the conservativeness of responsible disclosure best practices. Perhaps these practices are overly accommodating and diminish the urgency to fix vulnerabilities, protect users, and strengthen the security of supply chains. Perhaps it’s the responsibility of technology leaders to apply pressure and stress the importance of regularly maintaining and updating software. It’s their responsibility to better define what “adequate time to develop fixes and patches” means and how “proliferated” an update must be in the supply chain before vulnerability finders can move forward with public disclosure. The advent of IoT is only going to demand more security discipline across the supply chain, and squishy requirements like “adequate” and “proliferate” are not going to facilitate that.
Google’s approach allows their engineers to disclose details of vulnerabilities just 7 days after reporting them to vendors. Their approach is a significant departure from what we’re used to seeing in this industry—which has jarred affected vendors. Microsoft, one of these vendors, has subtly called out Google for their differing strategy and has expressed that, by contrast, they believe in “collaborating across the security industry in order to help protect customers. This includes disclosing vulnerabilities to vendors through Coordinated Vulnerability Disclosure, and partnering throughout the process of delivering security fixes.” Microsoft Offensive Security Research member Jordan Rabet also says it’s “problematic when the vulnerabilities are made known to attackers ahead of the patches being made available…. It’s important to ship fixes to customers before making this public knowledge.” The Microsoft vs. Google feud on responsible disclosure isn’t new. Synopsys security researcher Robert Vamosi reports on yet another responsible vulnerability disclosure spat between the two tech giants.
On the other hand, we should give Google credit for not only dishing out challenges but also following through on their own aggressive approach. Google has delivered fixed builds within a 7-day window; they’re leading by example. However, not all organizations are like Google. They may not have both the resources of a large organization and the nimbleness of a startup. We can’t expect this type of turnaround across all organizations and industries overnight.
Here at Synopsys, we’re committed to standing by the security and safety of vendors and their customers. So with every vulnerability found by Defensics, we’ve followed responsible disclosure best practices and collaborated with both vendors and information-sharing organizations throughout the entire process. This has been exemplified by our disclosure of high-profile findings such as Heartbleed and the responsible disclosure honors received by our researchers. For those of you who are not familiar with information-sharing groups, Synopsys participates in member-driven organizations such as ISACs to maximize communication of information we’ve discovered to asset owners and operators. If you’re a vendor and you haven’t already, we highly encourage you to join your sector’s ISAC today.
Don’t get us wrong. We understand responsible disclosure can be a long and tedious process, but we firmly believe delivering security fixes to the public in the safest way possible comes above all else. In fact, we believe it’s our social responsibility.
Get the latest AppSec news and trends sent directly to you.