Security journalists, for reasons that are not entirely clear, treat issuance of a CVE identifier for a claimed security vulnerability as a sign of significance and legitimacy. Take the start of an Ars Technica story from several months ago:

It sounds like something out of an urban legend: Some Windows XP-era laptops using 5400 RPM spinning hard drives can allegedly be forced to crash when exposed to Janet Jackson’s 1989 hit “Rhythm Nation.”

But Microsoft Software Engineer Raymond Chen stands by the story in a blog post published earlier this week, and the vulnerability has been issued an official CVE ID by The Mitre Corporation, lending it more credibility.

The post later noted this:

The CVE entry mentions “a certain 5400 RPM OEM hard drive, as shipped with laptop PCs in approximately 2005” and links back to Chen’s post as a primary source.

A commenter on the story noted the problem with that:

Isnt that circular supporting evidence? How can Chen’s article be lent credibility by an official CVE, while that CVE lists Chens article as a primary source?

Last week, we mentioned that the WordPress security company Wordfence was claiming that CVE information is reliable and comes from respected companies.

In reality, it looks like almost anyone can issue CVE ids through the CVE’s CVE Numbering Authorities (CNAs) program and they too frequently issued for false claims of vulnerabilities. CVE claims the CNA program involves companies that “demonstrate mature vulnerability management practices”, but we have run across multiple CNAs that clearly doesn’t describe. If you contact CVE to notify them of a problematic member of the CNA program, they will tell you that they can’t do anything about that (even know they could) and you need to dispute individual CVEs with the problematic CNA.

There isn’t an ability for the vendors of claimed vulnerable software to dispute a CVE id before it is publicly issued. That is a big problem, since false information is able to be given the legitimacy of CVE (as can be seen above) and only once the damage is being done can action be taken. But as we recently found, the situation is even worse than that, as the dispute process is broken. And not only is it broken, but it is broken in a way that suggests the CVE team isn’t very security minded.

Recently we were reviewing a claim that a vulnerability had been in a WordPress plugin used by at least one of our customers. The report on it was lacking the basic details needed to check if there really was a vulnerability and it had been fixed (we often find that vulnerabilities haven’t been fixed). The changes made in the version it was supposed to have been fixed suggested that there really hadn’t been a vulnerability. As there was a CVE id issued, we thought we might be able to figure out what was really going on by using their dispute process.

CVE’s Dispute Process

CVE put out version 1.0 of their CVE Program Policy and Procedure for Disputing a CVE Record (PDF) in September. One of the examples of why a record can be disputed is incomplete information:

Incomplete information: A Published CVE Record may lack sufficient information for the vulnerability to be re-created by a CVE Program stakeholder. In this case, the technology vendor, maintainer, or third party may dispute the CVE Record.

It’s unclear why a record would be allowed with incomplete information in the first place, since that seems to defeat the purpose of having a record, since they are supposed to provide a unique identifier for a vulnerability. If you can’t tell what the vulnerability is, how can you be sure that they are no multiple entries for the same vulnerability?

The first step in the process is to contact the CNA that issued the CVE id:

The party initiating the dispute must document their rationale for the dispute and submit
the rationale to the CNA. The disputing party should provide evidence and rationale as a
basis for the dispute (e.g., issue trackers, application security policy, engineering
findings).

We did that. The second step is for them to acknowledge that:

The CNA will acknowledge receipt of the dispute, in writing, within three business days.

Can you think of a problem with that?

The answer is that the CNA can simply ignore the dispute. That isn’t a hypothetical issue, as it has now been three weeks since we submitted our dispute and we haven’t gotten a response. The policy assumes that will happen, as the next step goes on from there:

The CNA will review the rationale and engage the appropriate stakeholders, as necessary,
to develop an understanding of the basis for the dispute.

Exploiting security vulnerabilities often involves misusing a system’s intended functionality in ways that were not intended, so security minded individuals are often good seeing holes in processes, which, in the best case, CVE appears to have failed to do here.

After waiting four business days for the CNA to respond, we contacted CVE about this problem with their policy. We asked what is the next step if the CNA doesn’t respond and what is the implication for a CNA if they simply refuse to respond to requests? We didn’t get an answer to those questions (and still haven’t gotten an answer). Instead, they said they wanted to help with the CNA and were asking to share the information we had provided CVE with the CNA. The relevant information about the dispute had already been provided CNA, and we were not looking for help with the CNA, but to address the problem with the process.

Two emails later, they said they were working on a proposal to update the dispute policy, though we don’t know if that is true.

In any case, it has now been three weeks since we disputed the CVE record and we still haven’t gotten anywhere. In this situation, it isn’t a big deal, but it could do significant damage for a company if false information about their security was allowed to remain up with a source treated as being trustworthy for this length of time.