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
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:
- Is the behavior I’m seeing intended?
- Can I configure/setup Greenbone to not match non-versioned software like this?
- 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!