Over 6,000 vulnerabilities went unassigned by MITRE’s CVE project in 2015

In 1999, MITRE created the Common Vulnerabilities and Exposures (CVE) database as a way to standardize the naming of disclosed vulnerabilities. Seventeen years later, the CVE system is faced with bottlenecks and coverage gaps, as thousands of vulnerabilities go without CVE-ID assignments.

These gaps are leaving business leaders and security teams exposed to vulnerabilities their security products, which rely on CVE-IDs to function and assess risk, don’t even know exist in some cases.

Before CVE existed, the public had access to IBM X-Force (1997) and the SecurityFocus’ BID database, which was established around six months before CVE. Each had their own methods of tracking and disclosing vulnerabilities, and this led to a situation where there wasn’t an easy way to determine if the different databases tracking such problems were referring to the same thing. MITRE Corporation, seeing an opportunity, created CVE to fix these issues.

CVE-IDs are issued by CVE Numbering Authorities (CNAs). MITRE is primary CNA, as well as the CNA of last resort when it comes to naming disputes. There are currently twenty-two organizations listed as CNAs, including Adobe, IBM, Cisco, Red Hat, Google, Apple, and Microsoft.

A CNA can request a pool of CVE-IDs from MITRE and assign them to vulnerabilities in their own products, but the frustration for some in the security industry is that these CNAs do so at their own leisure. MITRE says that it is difficult, but not impossible, to maintain consistency in CNA assignments and administration.

“To this end, the CVE program is currently developing new CNA rules to maximize the administration and execution of CNA assignments under a federated structure, including operational and governance models,” Jennifer Lang, the Senior Public Affairs Representative for MITRE explained.

These new rules are being developed by the CNAs themselves, MITRE, and the CVE Board as a collaborative activity, she added. A passive reading of both public and private email archives by Salted Hash shows that these new rules came about after strong urging from the CVE Board.

CVE touches a vast amount of the security industry. Organizations depend on CVE, or more specifically, its completeness, to assist with risk modeling, policy development, and daily operations.

Speaking on background with Salted Hash, a financial organization said it relies on CVE during vulnerability scanning to locate assets that need patching. This same organization also uses CVE in their threat intelligence and incident response programs.

Perhaps it’s a lack of resources, or a lack of understanding the rules, but the public discussions on the topic shows the disconnect between MITRE and the other CNAs has created confusion and serious problems in some cases, for years.

What would happen if a CVE-ID were issued for vulnerabilities in one vendor’s products, but that same CVE-ID was then cross-linked incorrectly to similar vulnerabilities in products from other vendors? This seems unlikely, but that’s exactly what happened with CVE-2014-8730.

CVE-2014-8730 is a variant of POODLE (or CVE-2014-3566).

The catch though, is that CVE-2014-8730 represents products from F5, an application technology company in Seattle, Washington. Notes on this CVE-ID assignment state that other “vulnerable implementations should receive their own CVE ID, since this is not a vulnerability within the design of TLS 1.x itself.”

IBM, Cisco, and HP all issued advisories for their products related to this issue, and each of them referenced the F5 CVE-ID incorrectly. This might seem like a non-issue, but such mistakes could lead to problems with metrics and vulnerability tracking, as well as situations where an advisory is given less weight, because the referenced CVE-ID referred to a vendor or product the organization didn’t use.

For their part, IBM said their PSIRT would correct the error. A Google search for 2014-8730 on ibm.com returns more than 2,000 results, which is what brought them to our attention.

“This particular CVE was assigned by MITRE first as encompassing everything to do with this vulnerability. Initial guidance from MITRE was that all vendors should use this CVE for advisories related to this vulnerability. After it was already assigned out via IBM PSIRT to IBM product teams, MITRE changed its guidance to recommend that the CVE be used only for F5 instead,” said Scott Moore, Vulnerability Database Team Lead for IBM X-Force.

“When MITRE released the updated guidance, IBM was already in the process of releasing fixes and bulletins for the vulnerability; because the revised guidance seemed to be a recommendation only, IBM did not modify the CVE, which would have delayed publication of bulletins.”

Days after this statement was sent to Salted Hash, on September 19, IBM modified a Flash Alert for critical updates to IBM DataPower Gateways, which incorrectly identified CVE-2014-8730.

Again, the gaps created by the divisions between MITRE and the CNAs are creating an invisible attack surface that’s already been exploited once.

In 2015, there were 6,356 vulnerabilities disclosed to the public that didn’t receive a CVE-ID. Thus, products or security teams that rely on CVE to function or perform their day-to-day operations were missing the full picture.

Looking at the metrics published by CVE Details, and comparing them to commercial CVE products (Risk Based Security’s VulnDB), that monitor and use MITRE’s work, as well as other sources to compile their data, there is a clear disconnect.

Why does MITRE not have assignments for vulnerabilities identified via other sources? Why haven’t the CNAs shared their own disclosures with MITRE so that CVE can reflect the information, instead of leaving entries in RESERVED status, which shows nothing? Why aren’t CNAs assigning IDs to all of the vulnerabilities they disclosed, since some of the unassigned vulnerabilities are in their products?

VulnDB shows 14,914 vulnerabilities disclosed in 2015. Within that set, only 8,558 vulnerabilities have CVE-IDs assigned to them. That leaves 6,356 vulnerabilities with no CVE-ID, and likely no representation in a majority of security products.

There are some important things to note with these figures. The Common Vulnerability Scoring System (CVSS) score, is an industry standard for assigning a numeric value to denote risk.

Some vulnerabilities missing a CVE-ID are listed as 10.0, which is ‘critical’ and others are much lower. However, if nothing is known about the vulnerability, it gets an instant 10, in order to stay within the CVSS scoring guidelines.

Second, while VulnDB abstracts when there are multiple vulnerabilities assigned to a single CVE-ID, it still represents 6,356 missing vulnerabilities. If MITRE and the CNAs added the missing 6,356 vulnerabilities to the database, it isn’t clear how many IDs those vulnerabilities would represent.

MITRE maintains a list of vendors and products that are considered ‘Tier 1’, or ‘must cover’.

That list is followed by Tier 2 organizations, which are designated as ‘should’ cover, and Tier 3, ‘can’ cover. Tiers 4 and 5 are designated as ‘may not’ and ‘must not’ cover (which only includes vulnerabilities specific to a website or service, not an end-user product, something that all of the major vulnerability databases agree on).

According to VulnDB, some of the Tier 1 organizations missing CVE-ID assignments for disclosed vulnerabilities in 2015, are Adobe (17); Apple (24); Cisco (29); Microsoft (33); MySQL (46); HP (12); IBM (60); Oracle (67 – there’s overlap with MySQL since Oracle’s acquisition); and SAP (174).

Moreover, there were 130 Supervisory Control and Data Acquisition (SCADA) vulnerabilities, and 51 medical device vulnerabilities, that went without a CVE-ID in 2015, as well as six electronic voting machine vulnerabilities. It is interesting to note that of the 278 electronic voting machine vulnerabilities disclosed historically, none of them have received a CVE-ID assignment.

While these numbers are bad, what’s worse is that the industry has already felt the impact of an attack against a vulnerability that wasn’t assigned a CVE-ID.

Earlier this year, on May 11, US-CERT issued the first ever alert geared towards SAP applications. At the time the alert was issued, at least 36 organizations globally had been impacted by attackers targeting SAP vulnerabilities that were patched in 2010.

Yet, regardless of the patch’s existence, the attacks and the issue itself caught the public off guard. Attackers had been hitting vulnerable systems since 2013, and while details of the vulnerability were logged in a number of places (i.e. Exploit DB / VulnDB), there was no CVE-ID assignment made, despite the fact that SAP is a Tier 1 organization according to MITRE.

On May 12, 2016 MITRE issued CVE-2010-5326 to account for the targeted vulnerability, almost six years after it was initially disclosed.

Salted Hash asked about the missing CVE-ID assignments in 2015.

In a statement, MITRE’s Jennifer Lang said it was difficult to answer the question, because without knowing the specifics on the vulnerabilities in question “the vulnerabilities are likely out-of-scope.”

“This does not mean the vulnerabilities themselves are unimportant, but rather that they currently do not fall under the program’s scope of coverage,” she added.

Cisco offered a similar statement, pointing to scope without actually using the term:

“For Cisco, a vulnerability is defined as a defect in a product or software that allows unauthorized device or network access, exposure of sensitive device information, or a bypass of security features or restrictions. A vulnerability is different from an attack that requires compromised credentials or physical access to a device. While the latter would not be assigned a CVE, it would still require hardening the network, implementing processes to prevent, detect and remediate.”

FireEye’s manager of Research Science, Dan Caselden, said that vulnerabilities are often patched without ever receiving a CVE-ID, adding that a CVE-ID might not be important “if the community has no need to discuss the vulnerability.”

Improvements in communication and coordination would potentially fix most of the issues Salted Hash has uncovered while looking into MITRE and the CVE project, but not all of them.

MITRE gets at least $1.2 million in taxpayer funding for CVE, out of a total government contract of $5 million (based on 2006 FOIA documents).

Funding on that level should certainly come with serious expectations, that now demand improvements, considering commercial vendors in the same space (IBM, Secunia, RBS, etc.) do it quicker and cheaper.

There is a mentality of covering only the big vendors and ignoring everything else, or assigning it a lower priority that ultimately never receives coverage.

That was acceptable in the ’90s when the world had relatively few software vendors, but these days, considering the impact of SCADA, the ‘Internet of Things’ (IoT), and self-service IT alone, that mindset doesn’t cut it.

Further, there is almost zero coverage of third-party libraries, other than OpenSSL, which is why the Tier lists need updating, badly. Libraries such as FFmpeg, ImageMagick, or PCRE can impact thousands of vendors and products when vulnerabilities are discovered. Many of the organizations on the Tier 3 list should easily move up, given their current size and market usage.

Another fix centers on the CNAs; Salted Hash observed several examples of CNAs issuing CVE-IDs incorrectly, but none of them face any sort of consequences or continuing education / additional training when this happens. The hope is that the new CNA rules being developed by MITRE and the CVE Board will begin to address this problem.

It isn’t easy; fixing something like CVE won’t happen overnight. But putting the effort into fixing it is worth it, because the entire industry relies heavily on CVE and the system is far from living up to its potential and expected taxpayer value.