CPE with wildcard not being matched

Scanning / scan configuration
1

Hello everyone.
I was scanning a host which has installed cpe:/a:7-zip:7-zip:9.20 [1], this is recognized by greenbone.
The scanner found 3 (as far as I see) CVEs which afflicts this version of 7-zip, only one though is linked under the cpe page of [1] in the web interface.
I checked the nvd.nist.gov page and the CVEs there are linked correctly. I.e., in the CVE page, in the “Known Affected Software” the cpe is present, though in a wildcard syntax. I don’t know if this is the cause of the problem.
To be more specific:

  • CVE-2016-2335 (this one is linked correctly in gse /cve/CVE-2016-2335, exact match is [1])
  • CVE-2018-10115 (this shows only cpe:/a:7-zip:7-zip:18.03 as vulnerable product, but on [2]/vuln/detail/CVE-2018-10115 there’s a pattern which matches all versions up to 18.03, correctly so)
  • CVE-2018-10172 (this shows only cpe:/a:7-zip:7-zip:18.01::~~~windows~~. My 9.20 7zip version is not matched as a consequence. On [2]/vuln/detail/CVE-2018-10172 you can see that there’s a long list of cpe if you click on “Show matching CPEs”, 18.01 is just the latest.

So, I don’t know, the problem seems to be that gsm is only grabbing the last entry in a list of cpe defined by wildcard?

[2] https://nvd.nist.gov
Thanks, regards.

2

Also, on NVD - Results, the list shows 8 CVEs, on gsa /cpe/cpe%3A%2Fa%3A7-zip%3A7-zip%3A9.20 only 1, probably the only one which doesn’t use wildcard to match (assumption)

3

Hello thomasorhym and welcome to the Greenbone community!

I don’t have time to check these cases in depth right now, but we do have a few issues with CPE-CVE matching currently. Some of them are due to incorrect data on the NVD side, but the problem with the wildcards looks to be on our side.

We are currently investigating how to proceed in this case, so unfortunately I do not have a solution for you at the moment.

Can you please open an issue here so we can further handle your bug report? - Issues · greenbone/gvmd · GitHub

2 Likes
4

I’m not 100% sure if this is really an issue in the manager / gvmd:

because it seems the SCAP data is incomplete similar to cases like the following in the past:

5

Those problems were solved with manual sync through greenbone-feed-sync, I’m using the containers, which don’t have any script to synchronize as of Improved Feed Sync for Greenbone Community Containers . The images are updated daily, a simple pull and run should copy the updated feed to the volumes. Nothing wrong in the logs.
On that note, Workflows - Greenbone Community Documentation is outdated (I guess, since greenbone-feed-sync isn’t in the gvmd container).