A few days ago, Tod Beardsley published an article on SC Magazine titled “An inside look at what makes the CVE Program tick“. Overall the article is well-written and offers some insights into MITRE, CVE, and their “CNA” program or CVE Numbering Authorities. Beardsley does a good job enumerating some basics about the program, the history of CVE, and the goals of it. However, there are some points I want to add clarity to.
First, Beardsley’s bio line says “director of research, Rapid7” which is his day job, but nowhere does it clearly say that he is also the Rapid7 CNA essentially, and only at the end does he talk about being a “involved in the CNA Coordination Working Group“, while not mentioning that he also serves on the CVE Board (formerly called the CVE Editorial Board). So he is a community-based advocate for the program which is important to mention since he has skin in the game and considerable bias. In so many words he is a CVE cheerleader. I on the other hand, was on the CVE Board for ten years but voted off the board, along with Carsten Eiram, in September, 2018. Suffice it to say, there are politics at play even in that world. Point is, I too am biased but I think my track record on the board shows that I was passionate about encouraging MITRE to improve and often at odds with what I saw as their apathy and lack of expertise in the world of vulnerability databases.
With that, here are some rebuttal and clarification points that I think are helpful to know for those wanting to better understand the CVE ecosystem. Some of this may sound pedantic, but note that I have done presentations and prior articles on the history of vulnerability databases (VDBs) and I think it is the tiny niche of expertise I have.
The CVE List stands as one of the oldest and most widely-referenced databases of security intelligence operating on the internet today.
As I have noted in several presentations, vulnerability databases in one form or another go back to the 1970s actually. There were over a dozen between what I consider to the be first, “Repaired Security Bugs in Multics” published in 1973. Between that list and CVE there were arguably at least 29 other lists of vulnerabilities or VDBs. If you wonder about my distinction of “lists” and immediately think they don’t count, please note that the founder of CVE and many of their staff over the years have been adamant that CVE is “not a VDB“. They are wrong, but calling it a list, “dictionary”, or a VDB doesn’t matter, the comparison is fair. While CVE is certainly the most widely-referenced database, it also most certainly is not one of the oldest. Note that I say “the” instead of Beardsley’s “one of” as far as being referenced, and I believe that cannot be argued. Finally, it is odd he chose to link “CVE List” to the CISA Exploited Catalog which is not a comprehensive list of CVE identifiers.
Today, it’s become quite strange for IT professionals to refer to a common software vulnerability without mention of its unique CVE ID.
This is an amusing Catch-22 of sorts, one based on what Beardsley said above about being so widely referenced. Because it is so widely used, of course people use a CVE ID when referencing a vulnerability. That is fundamentally how CVE works. What his point completely misses is the question more professionals should have been asking all along; “What about all the vulnerabilities without a CVE ID? How are they referenced?” If you are wondering how many that is, I know of over 93,500 I can pull up with a simple query in VulnDB and further, I bet there are another 50,000+ out there to be found buried on the Internet.
For example, take the much-discussed Log4j vulnerability, a quick glance at Apache Log4j Security Vulnerabilities shows that there are at least six CVE IDs associated with various versions of Log4j.
These distinct CVE IDs are crucial for people who are in the business of detecting and remediating these vulnerabilities in their own environments.
Consider these two sentences together and there is a vulnerability elephant in the room, one that has consistently gotten bigger the last five years. First, let’s assume he is talking about “Log4Shell” in the first part since he didn’t link to the CVE strangely enough, and worse, he linked to a SC article that also doesn’t cite the CVE. Second, then he links to the Apache Log4j security page and mentions six CVEs so we aren’t sure if he means there are six IDs for six versions of Log4j affected by that vulnerability, or if there are six distinct vulnerabilities in the Log4j software. If you don’t click through and start reading and counting CVEs, you can’t be sure.
If the first scenario then “The Log4j vulnerability” is singular, yet there are six CVE IDs associated with it? In reality there are four different CVE IDs associated with “the” Log4j vulnerability that most people think about (2021-44228, 2021-45046, 2021-4125, 2021-44530). Next, click through those and you see that 2021-4125 is still in RESERVED status almost five months after the disclosure of the vulnerability. Does that ID have any value as Beardsley originally stated (“distinct CVE IDs are crucial for people who are in the business of detecting and remediating“)? How about 2021-44530 which is a one-off assignment where Log4Shell as applied to the UniFi Network product. Log4Shell literally affects thousands of products yet they didn’t each get a distinct ID, so why did that one? That introduces confusion because MITRE is either lazy or apathetic in their stated goal of having a unique ID for each vulnerability. 2021-44530 should have been REJECTed long ago. So we have two IDs that really represent Log4Shell, one for the base vulnerability, one to represent the first attempt to patch which was determined to be incomplete.
What Beardsley meant is that there are six unique CVE IDs associated with Log4j on the page he links to (not Log4Shell), which has twenty total references to those six IDs. So, what is his point here? That “there are at least six CVE IDs associated with various versions of Log4j“? Sorry, that is incorrect. There are actually 15 CVE IDs associated with Apache Log4j that represent 11 unique vulnerabilities. There are also three more vulnerabilities that do not have a CVE ID assigned at all. Confused yet? You should be, and that is something that represents one of the biggest problems in the CVE ecosystem. Later in the article we see:
Take a look at Log4j vulnerability, CVE-2021-44832.
So Beardsley was talking about that vulnerability, but then doesn’t mention any of the other CVE IDs associated with it. Curious.
This agreement on a common, freely available, funded, and cross-product/cross-vendor indexing system for describing a vulnerability makes it possible for people using different security and auditing tools from different vendors and providers to know for sure they’re talking about the same thing. Precision matters in security.
Beardsley is right about some of that! Unfortunately, he chose one of the worst examples to demonstrate this because MITRE and CVE clearly do not make this (easily) possible, introduces more confusion than clarity, and offers no precision whatsoever.
I once heard Chris Levendis, program manager of the CVE Program, say something to the effect of: “There is no CVE fairy,” and that numbers don’t magically spring from the ether when new vulnerabilities are discovered and reported. They are described, documented, and assigned identifiers by human agents, just like the articles and statistics on IMDB and Wikipedia.
One nitpick here is that it explicitly is not like Wikipedia, where anyone can suggest an article and edit existing ones. That Wikipedia-style model was tried and the industry did not contribute to it (the Open Sourced Vulnerability Database or OSVDB).
Rather than ending up with a bottleneck at the MITRE Corporation, the CVE Program has seen an explosion of new CVE Numbering Authorities, or CNAs.
This sentence is misleading at best, factually wrong at worst. Despite there being CNAs who have the ability to assign IDs and publish their own advisories, until very recently all of the central CVE work still went through MITRE staff to publish the CVE IDs on their side. More recently, CNAs have been given Git-style access to do this work themselves from what I understand, but it still relies on them actually doing it. You probably know what I am going to say next… that they sometimes fail to do that. Unfortunate, but true. When those CNAs fail to do so, which is clearly stated in the CNA rules set forth by MITRE that they must update within 24 hours of disclosure (Secion 2.2.3), there is no accountability and no significant auditing done to discover and correct it. So the problem persists since the inception of the CNA program.
Today, if a researcher, software developer, or hacker discovers a new vulnerability in common software, chances are pretty good there’s a CNA for that.
No, there is a guarantee there is a CNA for that, because if a vulnerability fails to fall under the purview of a specific vendor CNA, then it falls back to MITRE who is the original or “root” CNA. There is always someone there to assign.
There, it’s possible for someone to search the hundreds of CNA contacts, pick the one that’s right, and fire off a friendly notification that they’ve found a bug and would like to assign it a CVE ID.
Except that isn’t how it works with many vendors either. While early intent of the CVE program was to “assign first, ask questions later“, many vendors will now ask questions first, analyze second, then assign an ID third if it is a valid vulnerability. You can ask a CNA to assign, but it doesn’t guarantee they will. In fact, if they dispute the vulnerability regardless of validity of the issue, they can refuse to assign too.
Take a look at Log4j vulnerability, CVE-2021-44832. While it’s a short description at just 80 words, there are a dozen or so references to much more exhaustive analyses. The descriptions of CVE IDs don’t contain discovery, reporting, exploitation, or fix credits, and they don’t give step-by-step instructions on how to fix them or exploit them.
There is so much to unpack here. First, a dozen references for Log4Shell is laughable. The associated entry in VulnDB for that vulnerability literally has thousands of references, citing hundreds of vendors that published advisories on over 1,600 products. The CVE description and references on the other hand force analysts to do even more digging, searching out each vendor that might be affected, and waste countless hours trying to determine if and where they are impacted. If they have to do that for every CVE…
Despite what Beardsley says in the article, which is simply due to being unfamiliar with a bulk of the entries, CVE doesn’t even reference the vendor, product, or version sometimes. In rare cases, the description conveniently omits all three or has the wrong vendor and product. If you wonder why I link to archived copies of these it is because yes, MITRE likes to fix them when I publicly call out such entries. They also have over half a decade track history of ignoring my emails when I pointed out such issues directly to them, so I stopped trying. Yes, they ignored me as a researcher, vulnerability database maintainer, and as a CVE Board member.
In other words, the identifier gives us just enough information to know what we’re talking about, but the guts of the vulnerability and who’s been involved in it are documented and discussed across several other websites and mailing lists.
This is a bold and very incorrect assumption. Vulnerability disclosures can be atrocious and not properly document a lot of vital information required to act on them.
CVE ID’s are a perfect example of the computer engineering axiom of, “do one thing, and do it well.”
Over 93,000 vulnerabilities I know of that don’t have a CVE ID suggests they do one thing, but not so well.
That’s not to say that CVE IDs don’t have loads of metadata, … but those elements remain optional elements in the current CVE data schema and up to the CNAs to provide.
Sorry, then CVE IDs do not have loads of metadata necessarily, and the metadata he does describe is what databases did in the late 1990s and early 2000s. That level of metadata is archaic and not something that should be boasted about. Even OSVDB, the attempted open-sourced Wikipedia-style attempt at a database, had 30 or more additional pieces of metadata by 2007.
It’s an exciting, expansive time in the history of the CVE Program, so join us to help shape its future.
Tried that, didn’t even get the T-shirt. MITRE was vehemently opposed to improvement for most of the ten years I banged my head against the CVE wall pushing for evolution in their process and mentality. I wish them the best but it was a lost cause when it comes to a viable vulnerability database. By that I mean that any organization that exclusively relies on CVE for their vulnerability intelligence has already lost the game.