CVE Identifiers Make Room For a Few More Digits

The deadline for a syntax change for CVE identifiers is coming on Jan. 13 when the four-digit format will support five or more. Vendors must update vulnerability management products to support the new syntax.

There was a time when 9,999 vulnerabilities in a calendar year was an exaggeration of the problem. There was no way—folks at MITRE said in 1999—that they would have to produce that many CVE identifiers. The syntax for CVE identifiers supporting four digits was an unnecessary cushion.

Yet here we are 15 years after that four-digit assumption was made and a major change is coming to CVE identifiers. Starting in January, MITRE will support a new numbering format for CVE-IDs one whose syntax will accommodate five or more digits. The current format, CVE-2014-xxxx, is coming close to outliving its usefulness.

As of this morning, MITRE principal information security engineer and CVE List editor Steve Christey Coley said the organization had produced almost 6,600 CVEs this year. With three-plus months to go, there’s a chance the four-digit format could be exceeded this year. Regardless, there will be at least one five-digit CVE produced on the deadline date of next Jan. 13.

CVEs are a globally accepted naming convention for vulnerabilities in commercial and open source software products. Researchers use them as referrers, vendors use them as common identifiers in vulnerability advisories, and vendors build products that work on the assumption that four-digit CVEs are here to stay.

And therein lies the problem: The new format could break vulnerability management efforts.

“In some cases, if a tool makes a four-digit assumption, it could stop functioning if it receives an identifier that violates that assumption,” Coley said. “The tool might see a five-digit identifier coming into it and stop working because it things the identifier is malformed.”

While product crashes would be noticeable, there could be less noisy failures. For example, vulnerability management products could truncate after four digits and point to an unrelated vulnerability.

“Consumers could end up underestimating the severity of an issue, and not think they have a vulnerability,” Coley said, who added that some programs that allocate enough memory for only four-digit identifiers could trigger a buffer overflow vulnerability.

Therefore, enterprises have to rely on vendors to be proactive about building in support for the new syntax. With 117 days to go to the deadline, 19 vendors are compliant with the new syntax, including Microsoft, NIST, CERT/CC, ICS-CERT and other big names. Hundreds of other vendors are not, not to mention the untold number of enterprises who wrote homegrown products that consume the current CVE syntax.

Coley said MITRE is making a final push before the end of the year to get the word out to avoid a Y2K scenario among vulnerability management products.

“It’s more than a fear of running out of numbers, it’s a future fact,” Coley said. “The only question is when it’s going to happen. We cannot predict when we’re going to wind up needing more than 10,000 identifiers in a year.”

The movement to establish a new syntax began in 2013 when MITRE engaged members of the security community and its own CVE editorial board to cover different possibilities. Some other options included adding alpha-numeric characters to identifiers , but that and other options were shot down. Coley said the decision was made earlier this year to add additional digits on an as-needed basis. The need is springing up not only because of the rate of vulnerabilities in software is spiking, but also because of the number of researchers and bug bounties urging smart people to poke around software looking for exploitable flaws.

“There’s no reason why we won’t wind up going to six, seven or more digits. It’s hard to imagine a world like that, but in 1999 when we made the four-digit assumption, we never imagined having more than 10,000 identifiers in a year,” Coley said. “The rate of vulnerabilities has been consistently and rapidly increasing. It’s a reflection of the massively growing vulnerability research industry. There are more researchers out there and more software than we had 15 years ago.”

Suggested articles