By Jake Edge
March 9, 2016
A recent discussion of problems with the Common Vulnerabilities and Exposures (CVE) system for security vulnerabilities—coupled with some efforts to supplement or supplant it—has led some to wonder about its future. The problems stem from the difficulty—sometimes impossibility—of getting CVEs assigned for real vulnerabilities. That, in turn, has led some to stop even requesting CVE numbers for vulnerabilities that they find, which further reduces their usefulness.
The system of assigning CVE IDs has been around since 1999—run by the MITRE Corporation . It was set up to provide a way for researchers, users, and others to track specific vulnerabilities, but has been seen as declining in quality over the years. For example, there are many CVE entries that have been assigned but simply show "RESERVED" with no details, which makes those entries less than entirely helpful.
The IDs do provide a way to refer to specific vulnerabilities, but that only works if the CVEs get assigned properly. As Kurt Seifried, who is part of the Red Hat security response team,put it on the oss-security mailing list, there is reason to worry about that:
So I’ve now heard from several security researchers that they are unable to get CVEs for issues that need CVEs (e.g. widely used hardware/software with flaws that have real world impacts and need to be properly tracked. This has definitely resulted in issues being publicized with no CVE that then makes it much harder to track and deal with these issues.
Beyond that, though, he has heard " about people that may have given up asking for CVEs and publicizing their work at all ". He also pointed to a message from Hanno Böck showing his inability to get a CVE assigned for a flaw in the implementation of a cipher used in TLS 1.2. The request was denied because it was " outside the scope of CVE’s published priorities ". Seifried concluded his message by noting that this new CVE policy that was cited in the message to Böck has two levels of coverage for the priority of CVE assignments, which is something he called " tiered coverage ". That policy may lead in undesirable directions, he said:
We will have significantly less CVE coverage in a time where security issues are literally exploding and becoming much more of a problem leading to a situation where I fear that CVE will not be as useful anymore. As CVE is the cornerstone of our industry for identifying vulnerabilities and making it much easier to track and search for them I think it’s critical that we re-examine this [tiered] coverage policy that Mitre arbitrarily decided to enact.
Others who posted in the thread largely agreed with Seifried’s concerns. Others echoed Böck’s experience and noted that they had given up even trying to get CVEs for the vulnerabilities that they find. The process to request a CVE ID is in place, but it isn’t smoothly functioning these days. Adam Caudillsummarized some of the problems:
Researchers request CVEs, and the requests are rejected because of this coverage policy (assuming the researcher gets a response; anyone that has watched this list has seen the issues with requests not being responded to). By rejecting these requests, and leaving legitimate vulnerabilities in software with a significant user base without a CVE, it makes work for difficult for researchers, for vendors, and for customers.
Caudill (and others) called for a new system of some sort. A participant known as "Tim"posted some detailed thoughts on what a new system might look like. As it turns out, though, Alexander Peslyak (better known as "Solar Designer") had created a bare-bones system to assign OVE IDs (OVE presumably stands for "Openwall Vulnerability Entries"). This assignment mechanism does no verification and simply assigns an ID; it is meant to be a friction-free mechanism to get an ID without needing vetting of any kind.
While the benefit of being able to get IDs quickly and easily was of interest, several in the thread were looking for more. Features such as allowing entries to be updated with more information or be curated in some fashion were mentioned. Solar Designersaid that he didn’t want to add more features, but encouraged others to pursue that path. As part of that discussion, Timnoted a major problem that he has seen: link rot for advisories and other detailed information. As he put it:
I can’t tell you how many times I’ve found a vulnerability scanner detecting an issue, and I go back to get more details to understand the risk, only to find all the technical details have been taken offline. It is a major gap in the security community’s (and IT industry’s) tool set that we don’t have a reliable, single archive of vulnerability information. It is a huge waste of time looking up every bug. And when I say "reliable" I merely mean the information won’t go away tomorrow (like the old FD [full-disclosure mailing list] did so suddenly). I don’t mean the information must always be true or validated, just available.
That led "halfdog" topropose a blockchain -based database to contain the vulnerability information, with "proof of work" providing a means to allocate the IDs. In the proposal for a "Distributed Cryptoenhanced Vulnerability Enumeration" (DCVE), there are provisions for storing some information with each entry, though it would not seem to completely eliminate the problem that Tim described.
There was also a pointer in the thread to the Open Vulnerability ID (OVI) system, which is another ID-assigning mechanism.
It’s not clear how much traction any of those systems mentioned would actually get, at least partly because they are entirely separate from the CVE ID namespace. Another project, which wasannounced by Seifried on the list, is the Distributed Weakness Filing (DWF) system. It directly incorporates CVE IDs into its database , so that DWF-2016-NNNN is the same as CVE-2016-NNNN. Other vulnerabilities that did not have CVEs could use numbers outside of the CVE numeric range (which is now arbitrarily long, but has never gone beyond four digits—yet). The DWF project, Seifried noted, is not part of his Red Hat duties; it is a side project that he and others are working on.
DWF provides a number of different ways to get an ID, starting with just trying to get a CVE number as usual, through requesting one from a DWF Number Authority (DNA), to changing the project’s database file and making a pull request on GitHub—or by simply emailing the project. As he said in the announcement: " I want to reduce the time and effort needed to get identifiers, something best achieved by pushing assigning out to as close to the vulnerability discover/handling as possible ".
So far, there has been little public reaction to the DWF announcement, but it certainly seems to be the furthest along in terms a new system. It complements the existing CVE system, while also setting up something that could replace it someday if the CVE system continues down its current path.
It seems clear that the CVE system is breaking down in various ways. The tiered coverage approach that MITRE has chosen does not look likely to help it back onto a path where it will be the definitive resource for vulnerability IDs. It’s also unclear whether any of the proposed alternatives will truly take off, but the free-software community would seem to be a likely candidate to start heading toward some alternative. If independent security researchers make the same choice, we could be seeing the beginning of the end for CVEs—though it is hard to imagine that system fading away completely.
( Log in
to post comments)