Reporting Capability for CVE Records That Lack Sufficient Information for the Vulnerability to Be Re-Created

[PluginVulnerabilities]

Proposed New Idea/Feature (required)

According to CVE's dispute policy, published CVE Records are supposed to have "sufficient information for the vulnerability to be re-created by a CVE Program stakeholder," but recently we have repeatedly seen developers of WordPress plugins complaining about claims of unfixed vulnerabilities from CNAs backed by CVE Records that lack even basic details. Here is a recent example of that. The lack of information is making it hard for them to try to address the vulnerability or explain why it isn't a vulnerability.

That is a problem for those using the software as well.

It also precludes making sure that there is only one record for vulnerabilities, since there isn't the information needed to check if another CVE ID has already been issued for the same vulnerability. We have been seeing plenty of apparent duplicates, but the lack of information makes it hard to say for sure.

Currently, there isn’t a mechanism to report this situation with a CVE record and therefore a method to monitor for CNAs repeatedly failing to provide the needed information. Adding a mechanism for that would help to address the problem.

Additional Notes (Optional)

[zmanion]

I couldn't easily find any evidence for CVE-2023-50855 beyond the claim in the Patchstack advisory. After some digging, I found this thread.

This does seem to be a valid case for a CVE ID assignment. Finder, Patchstack, the developer, and some helpful community members all seem to believe that an SQLi vulnerability exists, and it is public in some form. CVE does not require that vulnerability details are public, consider the many CVE Records for vulnerabilities in proprietary software.

If the developer was not given sufficient detail to identify and/or reproduce the finding, that would IMO be a poor quality vulnerability report from the finder or Patchstack. I suggest the problem is more about vulnerability reporting than CVE assignment.

I understand how a "insufficient public information" tag would be helpful, but I think the effort required to adjudicate and maintain such data would be considerable.

[PluginVulnerabilities]

Here is what the CVE dispute policy says in full related to this:

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.

That suggests to us that a complete record would contain information you are saying is not required, not that there is simply insufficient public information in that situation. If somewhere else CVE has a policy that contradicts that, then it seems like there is a discrepancy for CVE to address. It seems like there may be a tension here between a system that seems designed to allow software developers to issue CVE IDs for vulnerabilities in their own software and a system that also allows third-party security providers selling access to information about vulnerabilities to issue CVE IDs for software they have no connection to and based on claims of vulnerabilities that were directed away from the software developers to them.

If vulnerability reports are as vague as the one you are mentioning, then there is no way to, among other issues, make sure there are not multiple CVE IDs issued for the same vulnerability. So it seems like either reports need to be more public than what you are claiming they have to be included or CVE can't ensure that there are not multiple CVE IDs for one vulnerability. Right now, there are both problems. Here is one of the CNAs repeatedly mentioning that CVE IDs they are issuing appear to have duplicates. Here, for example, is one where they are saying the duplicate is one issued by Patchstack. The duplication hasn’t been addressed (nor has it been for others listed by the CNA that we checked). Even Patchstack doesn’t seem to be able to tell from their own vague information that they are listing a duplicate, considering they have two listings for the vulnerability, one using their issued CVE ID and the other using the other CNAs, in their own dataset.

The vulnerability reporter there and the assigner are one and the same, Patchstack. So saying that isn't a CVE assignment issue doesn't really make sense. Patchstack didn’t provide the developer with sufficient detail to identify and/or reproduce the finding. Here is what the developer said in what we linked to previously:

that link is basically worthless, because it doesn’t mention anything specific about the bug. There are no steps to reproduce it, or any lines of code mentioned that are vulnerable.

The developer isn’t complaining about too much information being provided; they are complaining of the opposite.

Another developer who has had the same problem, and who we are helping to deal with that, thumbs upped our idea.

Patchstack deals in WordPress vulnerabilities, all of that is open source software, so the proprietary element mentioned wouldn't apply. Considering that Patchstack uses the issuance of CVE IDs as a reason to report vulnerabilities to them instead of developers, it seems highly problematic for them not to be required to publicly release the information. It doesn’t seem like CVE’s intent is to direct vulnerability reports away from developers and then require that they have to deal with a third-party who redirected away the information from them.

What you are linking to from Patchstack is their standard report, which lacks even basic information. Check out another recent report that is identified is CVE-2023-51534 (though the record is empty). That appears to be related to a vulnerability that was listed as being fixed in version 0.6.3 of the relevant software. We know that the vulnerability attempted to be fixed wasn't fixed, because of the information the developer mentioned in the changelog and our subsequent review of the changes made. That is something the developer partially acknowledged, as they made another incomplete attempt at a fix in the next version, after we notified them it wasn't fully addressed. Patchstack's report lacks the information needed to confirm they are describing the same issue or to see that the vulnerability hasn't been fixed. If it is related, the required privilege listed by Patchstack is not accurate either. It's hard to see what the purpose of having a CVE Record in that situation is, considering that it can't be used to uniquely identify a vulnerability and it is probably wrongly claiming that a vulnerability has even been fixed (and without a way for that be verified one way or the other).

The effort to adjudicate and maintain such data shouldn’t be considerable, as it should allow addressing problematic CNAs quickly. If it is considerable, that would suggest there is a problem that CVE is continually not addressing, which the data should have allowed them to address.

[zmanion]

Anyone can dispute a CVE Record, based on assigning a CVE ID in the first place, or content (or lack thereof) in the CVE Record.

There is too much space and time between what is written down about CVE and what is commonly interpreted and practiced. One reason I commented on this issue is that we are revising the CNA Rules. We are generally aware of the concerns you are raising, and wanted to see if we can address the concerns during this rule revision.

In practice, many, many CVE Records do not contain or reference sufficiently detailed information for someone to "re-create" or de-duplicate. In practice, when a vendor or developer claims there is a vulnerability by assigning a CVE ID, that is accepted, even without detail. From the current CNA Rules:

7.1.1 If a product owner considers an issue to be a vulnerability in its product, then the issue MUST be considered a vulnerability, regardless of whether other parties (e.g., other vendors whose products share the affected code) agree.

And all of 8 CVE Record Requirements, which are fairly limitied.

[zmanion]

The WordPress plugin vulnerability management space seems to be particularly prone to low quality information, including duplicates. There are 236330 CVE Records. The Program has, over the last 5+ years, made some intentional choices to distribute and federate effort and responsibility. Yes, this leaves room for poor assignment or content issues, accidental or intentional. The current model, for better or worse, is for someone who knows and cares to dispute an assignment or record content.

[zmanion]

CVE-2023-51534 (at least rignt now) is "reserved but public (RBP)" and is considered to be a bad practice. We are expecting to make that practice more explicitly bad in the rules revision.

[zmanion]

And getting back to your original idea, I think a "insufficient information" tag is a reasonable feature to add, but more consideration is needed around how the tag can be set, cleared, investigated, etc. The existing method to comment on a published CVE Record (including to dispute it) is manual: https://cveform.mitre.org.

[PluginVulnerabilities]

In practice, when a vendor or developer claims there is a vulnerability by assigning a CVE ID, that is accepted, even without detail.

What we are seeing an issue with doesn’t involve CNAs who are vendors or developers, but third-party security providers who are selling access to information about vulnerabilities. Vendors or developers shouldn’t have an interest in falsely claiming their solutions contain vulnerabilities. But that isn’t always true for others.

Perhaps this could be a feature that doesn’t apply to vendors or developers.

The current model, for better or worse, is for someone who knows and cares to dispute an assignment or record content.

If a CNA is systematically problematic, disputing it with them each time is unlikely to be an approach that much of anyone is going to take. That is where having a method to monitor for continuing problems could help. Right now, even other CNAs do not appear to be trying to address the problems, as appears to be the case with the CNA aware of duplications mentioned above.

The existing method to comment on a published CVE Record (including to dispute it) is manual

Currently, the records page on cve.org doesn’t appear to include any indication that a record can be disputed. Much less, provide information on how to get in touch with the pertinent CNA to dispute it with them.

With unpopulated records, the records page on cve.org page doesn’t even list the CNA, so you wouldn’t even know who you are supposed to be disputing it with. If they are “reserved but public (RBP)”, maybe the CNA should be shown.