Software Integrity


Why there are at least 6,000 vulnerabilities without CVE IDs


A new investigation suggests that up to six thousand software vulnerabilities lack CVE-ID.

In a rather long article in CSO, Steve Ragan explains that in 2015 alone there were 6,356 vulnerabilities disclosed to the public that didn’t receive a CVE-ID. Ragan bases his claim on the fact that another vulnerability database, VulnDB, shows 14,914 vulnerabilities disclosed in 201 but 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.

Common Vulnerabilities and Exposures (CVE) is a standard reporting convention for publicly known information security vulnerabilities. The CVE Identifiers (CVE-ID) are used to enumerate different vulnerabilities. According to VulnDB, some of the missing CVE-IDs for disclosed vulnerabilities in 2015, are those for software from Adobe (17); Apple (24); Cisco (29); Microsoft (33); MySQL (46); HP (12); IBM (60); Oracle (67 – there’s overlap, Regan notes, with MySQL since Oracle’s acquisition); and SAP (174).

By industry vertical, Ragan says there were 130 Supervisory Control and Data Acquisition (SCADA) vulnerabilities, and 51 medical device vulnerabilities, that went without a CVE-ID in 2015.

There’s another problem with the current naming schema. There are 22 CVE Numbering Authorities (CNA). These include Adobe, IBM, Cisco, Red Hat, Google, Apple, and Microsoft – which might account for the missing CVE-IDs.

Being a CNA means the organizations control blocks of CVE-IDs which they can use for their own vulnerabilities. The trouble is the connection between MITRE and these CNAs is poor. So, logically, MITRE could issue a CVE-ID and one of the CNAs could use that same number for their own. That has happened.

From Ragan’s article the classic example is CVE-2014-8730 which is a variant of POODLE (or CVE-2014-3566). The catch, though, is that CVE-2014-8730 only 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.” Subsequent to that designation, IBM, Cisco, and HP all issued their own advisories for their products related to this issue, and each of them referenced the F5 CVE-ID incorrectly. Regan says this particular case might be an issue, but such mistakes could lead to problems with metrics and vulnerability tracking. There are situations where an advisory might be given less weight in severity because the referenced CVE-ID referred to a vendor or product the organization didn’t use.

The entire article is worth a read, a fascinating look into the bureaucracy around naming and numbering vulnerabilities. However, this confusion is leading others to create their own systems. For example, the distributed weakness filing (DWF) system has been created by Red Hat employee and MITRE board member Kurt Seifried together with researchers Larry Cashdollar, Zachary Wikholm, and Josh Bressers.

Despite its flaws, CVE-IDs remain an important foundation for security researchers and products.