search

cisagov / vulnrichment

A repo to conduct vulnerability enrichment.
Creative Commons Zero v1.0 Universal
406 stars 29 forks source link

CPE incorrect for xpdf #3

Closed prabhu closed 1 month ago

prabhu commented 2 months ago

🐛 Summary

Vendor string used for this xpdf CVE is xpdf.

https://github.com/cisagov/vulnrichment/blob/develop/2024/4xxx/CVE-2024-4568.json#L136

NVD, however uses glyphandcog as the vendor, similar to tukaani for xz.

https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=xpdf

Expected behavior

CPE strings must match NVD, where possible.

Any helpful log output or screenshots

Paste the results here:

Add any screenshots of the problem here.

prabhu commented 2 months ago

Possible there are more instances.

Here for example, the vendor used is aio-libs_project, while NVD has aiohttp. https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=aiohttp

https://github.com/cisagov/vulnrichment/blob/5140a8995b4641d58fa9162d3694bd4d9ef681ed/2024/30xxx/CVE-2024-30251.json#L125C48-L125C55

todb-cisa commented 2 months ago

Thanks so much, @prabhu!

amanion-cisa commented 2 months ago

Some explanation, which may or may not address the specific instances you noticed (which we will review!).

CPE strings must match NVD, where possible.

Yes, and this is how the process is designed to work. And...

  1. There is the official NVD CPE Dictionary. First choice. However, even that has matching issues, for example, some xpdf entries use xpdfreader as the vendor.

  2. Next, there are a number (84K+) of CPE entries in NVD data that are not in the Dictionary (1.2M+). Second choice (use something that exists).

  3. Last choice is to create new CPE. In this sense, we're following the CPE specification, but publishing CPE-compliant data does not get it added to the Dictionary.

Let's be clear, CPE is an attempt to address the wicked problem that is consistently naming all the software. Neither the CPE specification nor existing CPE data can do this, but it's a start, and an existing data set (or sets). There will be errors, and part of this process is to evaluate how CPE or other software identification systems work in practice.

prabhu commented 2 months ago

Thank you for reviewing this issue. From an ADP consumer point of view, 1 and 2 are straight forward. For 3, where a CPE was made up, is there a way to capture this information in the json, to inform the downstream tools?

May be this project would benefit from the new IDs supported by CVE schema 5.1 in the future, so perhaps a roadmap for update could be proposed.

serkanozkanssc commented 1 month ago

I was randomly browsing the repo and noticed that the CPE information for 2024/34xxx/CVE-2024-34342.json is incorrect. I don't think https://github.com/wojtekmaj/react-pdf is the same as cpe:2.3:a:pdf.js_viewer_project:pdf.js_viewer::::::wordpress::*.

Also for 2024/34xxx/CVE-2024-34408.json I don't think the CPE should be cpe:2.3:a:tencent:tencent:5.8.2.5300:::::windows::.

FYI

todb-cisa commented 1 month ago

@serkanozkanssc would you mind opening this as a separate issue?

todb-cisa commented 1 month ago

Actually, having talked about this, I think we need a strategy for a) picking between close but ambiguous CPEs (lol that those exist) and b) taking feedback on evidence-based reasoning as to why the original CPE was incorrect.

In the meantime, this particular XPDF things was updated.