Supplementing CVEs with !CVEs

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out bybuying a subscription and keeping LWN on the net.

TheCommon Vulnerabilities and Exploits(CVE) system is the main mechanism for tracking various securityflaws, using the omnipresent CVE number—even vulnerabilities with fancy names andweb siteshave CVE numbers. But the CVE system is not without its critics and, intruth, the incentives between the reporting side and those responsible forhandling the bugs have always been misaligned, which leads to abuse ofvarious kinds. There have beenefforts tocombat some of those abuses along the way; a newlyannounced"!CVE" project is meant to track vulnerabilities "that are notacknowledged by vendors but still are serious security issues".

The "!CVE Team" posted the announcement to the oss-security mailing list onNovember 8; the project had just beenpresentedat Black Hat Toronto by Hector Marco and Samuel Arevalo fromCyber Intelligence, S.L., which is aSpanish security research firm. Given that Cyber Intelligence is the solepartner listed on the!CVE web site, it is hard not to come to theconclusion that Marco and Arevalo are part of (or all of) the !CVE Team,though its membership isostensibly anonymous.

The reasons behind the new project are pretty straightforward: trackingvulnerabilities that the relevant CVE Numbering Authority (CNA) hasrejected for CVE assignment. CNAs are delegated to assign CVEs for aparticular product or project, which, in many cases, is the same as thevendor or project itself. The announcement quotes theCNA rules:"CNAs are left to their own discretion to determine whether something is a vulnerability". Since the CNA is often the same as theone whose code is implicated, the announcement noted that there is a problem:

This poses a clear conflict of interest, since the same vendor is the onedeciding whether or not an issue is a vulnerability and therefore whether aCVE is assigned to their own product or not.

The solution, according the project, is to have a panel of experts evaluatereports of these kinds of vulnerabilities; if theyqualify, a!CVE-yyyy-nnnn identifier will be assigned and an entry will be created inthe NotCVE database. As might be guessed, the exclamation point in theidentifier was not popular, with Alexander "Solar Designer" Peslyakpointingout flaws in the numbering scheme in the first response to the announcement:

Please make these more distinctive, so that searching (e.g. the web ormailing list archives) for CVE-2023-0001 wouldn't find both the actualCVE and the !CVE, which are likely totally unrelated to each other. Infact, searching specifically for the !CVE could be difficult as theexclamation mark may be dropped by the tokenizer when indexing content.

He also noted that he hadcreated a CVEalternative, calledOVE,back in 2016, though it never really went anywhere; "Maybe yourswill." David A. Wheelersuggestedusing "NotCVE" rather than "!CVE", which is what the team eventuallydecidedto adopt. Looking up the first alert will work usingeither identifier, since there may be existing references to!CVE-2023-0001.

At this point, NotCVE-2023-0001 has only been joined byNotCVE-2023-0002,which is, somewhat ironically, a buffer overflow inNVD Tools. Thatproject provides a set of tools to work with theNational Vulnerability Database, whichincludes CVEs among the vulnerability information that it tracks.

In the thread, Mike O'Connorasked aboutnon-vendor CNAs, noting that the GitHub CNA is responsible for lots ofopen-source projects it hosts, but is hardly the "vendor" for them. Hesuggested that there are cases where CNAs are legitimately rejecting CVEassignment:

Perhaps they don't wantto build deprecated decades-old code to scope out the severity of abuffer overflow some random fuzzbot found. How would !CVE work forthe Linux kernel, where most security fixes have git commit hashes butnot CVEs?

The !CVE Teamsaidthat the project would only be tracking vulnerabilities that are not beingassigned CVEs—for any reason. It is not only for vulnerabilities that havebeen rejected for CVE assignment, there is more to it than that:

!CVE project is tracking, identifying and sharing security issues that otherwise would be randomly published in blog posts, Twitter, etc, (in the best case) or just lost. To obtain a NotCVE is not relevant whether someone is getting difficulties to obtain a CVE for their vulnerability or not. To get a NotCVE the issue must qualify.

O'Connor had also suggested working with the CVE project, "addressingwhat CNA rules you think may be broken", but the !CVE Team said thatMITRE (which runs the CVE project) is not unaware:

This is not something new or unknown by MITRE or vendors. In some cases MITRE is in favor of assigning a CVE but the vendor is against. In those cases MITRE can do nothing and by experience we can tell you that at the end CVE will not be assigned. Note that "the security issue" cannot be even named "vulnerability" because it is not (vendor is the only one with this authority) according to MITRE rules. If something is not a "vulnerability" there is nothing to patch, nothing to track, etc. Since those issues go unnoticed, they should be looked at even more cautiously since they are probably not going to be fixed.

At first blush, tracking untracked vulnerabilities seems like a perfectlyreasonable idea—and it is—but there are some risks to it as well. Thebiggest problems with the current system stem from misaligned incentives;researchers push for CVE assignment for personal-recognition purposes, whilecompanies and others sometimes want to forgo CVEs in order tonot berecognized as having a security flaw. Meanwhile, governments and othersbase legislation and agreements around fixing CVEs in short order, whichgives vendors and projects another reason to avoid them.

Beyond that,there arebogus CVEs that projects have tograpple with if they do not create their own CNA. The usefulness ofNotCVEs is going to come down to how well the "panel of experts" does in keeping bogus reports fromgetting added. If the NotCVE system were to become popular, it wouldprovide another target for researchers who are only concerned with personalrecognition, so the project might well be inundated with bogus reports ofvarious kinds.

The CVE system is, in short, a mess—and one that periodically spawnsattempts to fix orreplace the CVE system. So far, at least, none of those efforts hasgone very far and !CVE looks likely to join that club. But the problems itis trying to address, remain. So we will probably see more sporadic,generally quixotic,tilts at the CVE windmill over the coming years—decades and more, even.