CVE definitions seem to be missing version ranges

Archive Feed Services (GCF & GSF)
1

greenbone-nvt-sync --feedversion 202208041338
greenbone-feed-sync --feedversion --type SCAP 202208040426
greenbone-feed-sync --feedversion --type CERT 202208040617
greenbone-feed-sync --feedversion --type GVMD_DATA 202208041333

gvmd --version
Greenbone Vulnerability Manager 21.4.5
Manager DB revision 242

For the 3+ weeks our CVE scanner results have been matching 100s of CVEs against the base non-versioned CPEs, e.g. cpe:/a:oracle:mysql with a vendor:product but no version.

It looks like version numbers are defined on NIST but that Greenbone is dropping them.

I think this dates to a feed change ~16 July. I’m sorry I didn’t keep proper records to confirm!

An example is CVE-2022-21284.

The data on NIST shows this matching four MySQL version ranges NVD - CVE-2022-21284

image
image896Ă—506 35.6 KB

And as raw data 2022-23 Change Timeline

But the feed data Greenbone uses looks like this, from /var/lib/gvm/scap-data/nvdcve-2.0-2022.xml:

<entry id="CVE-2022-21284">
    <vuln:vulnerable-software-list>
      <vuln:product>cpe:/a:oracle:mysql</vuln:product>
      <vuln:product>cpe:/a:oracle:mysql</vuln:product>
      <vuln:product>cpe:/a:oracle:mysql</vuln:product>
      <vuln:product>cpe:/a:oracle:mysql</vuln:product>
      <vuln:product>cpe:/a:netapp:oncommand_workflow_automation:-</vuln:product>
      <vuln:product>cpe:/a:netapp:oncommand_insight:-</vuln:product>
    </vuln:vulnerable-software-list>

I.e. it looks like Greenbone is dropping the four software ranges 7.4.0 → 7.4.34, 7.5.0 → 7.5.24, 7.6.0 → 7.6.20 and 8.0.0 → 8.0.27 and treating them each as just “cpe:/a:oracle:mysql”.

This results in CVE scan results with over a 1000 matches against cpe:/a:oracle:mysql.

I think this is probably a mistake rather than by design? An argument could be made that if you don’t know the version of the software you should assume the worst and match everything against it… but I don’t think that was the intention here.

Also, I think this means if our initial scan detected cpe:/a:oracle:mysql:8.0.0, i.e. a CPE known to have this problem, then it would fail to match against CVE-2022-21284 as Greenbone has it defined.

What we’ve ended up doing is post-processing the CVE scan results and discarding all matches against non-versioned CPEs. Without this there’s too much noise.

My questions:

  1. Is the behavior I’m seeing intended?
  2. Can I configure/setup Greenbone to not match non-versioned software like this?
  3. Do I understand it correctly that this will match CVE-2022-21284 against cpe:/a:oracle:mysql but not cpe:/a:oracle:mysql:8.0.0?

Thanks very much for your time!

2

Hello khesterprotonm,

thank you for the detailed bug report! This does not look like expected behaviour, but I cannot say what’s going on here at the moment.

I have forwarded this issue internally for investigation and we’ll get back to you.

Please note that we currently only support CPE version 2.2 in our products, but the issue is the same in both cases.

3 Likes
3

Hi,

I’ve implemented a fix for this issue. You should get updated CVE data in the feed today or tomorrow. Please let me know if this is fixed for you now.

5 Likes
4

Thank you both for your quick responses.

Yes, I can happily confirm this is fixed.

Thanks for your help!

4 Likes