Support previous version matching

[mcfrisk]

Hi,

cve-check-tool as integrated into yocto cve-check feature fails to detect CVE's which match to certain SW version and previous versions. For example the systemd "0day" bug CVE says:

https://nvd.nist.gov/vuln/detail/CVE-2017-1000082

Vulnerable software and versions Switch to CPE 2.2
Configuration 1
OR
cpe:2.3:a:freedesktop:systemd:233:*:*:*:*:*:*:* and previous versions

The version 233 is marked as vulnerable but also all older versions (Debian security tracker states that 229 version introduced the feature, https://security-tracker.debian.org/tracker/CVE-2017-1000082 ).

Unfortunately, the NVD 2.0 XML schema feed from NIST does not support the "and previous versions" annotation and thus lists only systemd 233 as vulnerable:

$ zless nvdcve-2.0-2017.xml.gz
...
  <entry id="CVE-2017-1000082">
    <vuln:vulnerable-configuration id="http://nvd.nist.gov/">
      <cpe-lang:logical-test operator="OR" negate="false">
        <cpe-lang:fact-ref name="cpe:/a:freedesktop:systemd:233"/>
      </cpe-lang:logical-test>
    </vuln:vulnerable-configuration>
    <vuln:vulnerable-software-list>
      <vuln:product>cpe:/a:freedesktop:systemd:233</vuln:product>
    </vuln:vulnerable-software-list>
    <vuln:cve-id>CVE-2017-1000082</vuln:cve-id>

Thus a scan for systemd version 232 will not show that it is vulnerable to CVE-2017-1000082:

$ cat /tmp/cve-faux-YfM5Ot 
systemd,232,,
$ cve-check-tool  --no-html  --csv  --not-affected  -t  faux -d  /home/builder/src/base/../downloads/CVE_CHECK  /tmp/cve-faux-YfM5Ot

Only version 233 will show the issue and others as a vulnerability:

$ cat /tmp/cve-faux-YfM5Ot systemd,233,,
$ cve-check-tool  --no-html  --csv  --not-affected  -t  faux -d  /home/builder/src/base/../downloads/CVE_CHECK  /tmp/cve-faux-YfM5Ot
systemd,233,CVE-2017-9217 CVE-2017-9445 CVE-2017-1000082,,0

This seems to be a common limitation in NVD 2.0 data, BUT the information is still in 1.2.1 XML data format of https://nvd.nist.gov/vuln/data-feeds#CVE_FEED

https://nvd.nist.gov/download/nvdcve-2017.xml.gz

  <entry type="CVE" name="CVE-2017-1000082" seq="2017-1000082" published="2017-07-07" modified="2017-07-12" severity="High" CVSS_version="2.0" CVSS_score="10.0" CVSS_base_score="10.0" CVSS_impact_subscore="10.0" CVSS_exploit_subscore="10.0" CVSS_vector="(AV:N/AC:L/Au:N/C:C/I:C/A:C)">
    <desc>
      <descript source="cve">systemd v233 and earlier fails to safely parse usernames starting with a numeric digit (e.g. "0day"), running the service in question with root privileges rather than the user intended.</descript>
    </desc>
    <loss_types>
      <avail/>
      <conf/>
      <int/>
      <sec_prot admin="1"/>
    </loss_types>
    <range>
      <network/>
    </range>
    <refs>
      <ref source="MLIST" url="http://www.openwall.com/lists/oss-security/2017/07/02/1" adv="1" patch="1">[oss-security] 20170702 systemd fails to parse user that should run service</ref>
      <ref source="BID" url="http://www.securityfocus.com/bid/99507">99507</ref>
      <ref source="CONFIRM" url="https://github.com/systemd/systemd/issues/6237" adv="1" patch="1">https://github.com/systemd/systemd/issues/6237</ref>
    </refs>
    <vuln_soft>
      <prod name="systemd" vendor="freedesktop">
        <vers num="233" prev="1"/>
      </prod>
    </vuln_soft>
  </entry>

Note the prev parameter in vers of product systemd. Of course comparing two version numbers need to be supported some how, but for that there are quite standard solutions like https://stackoverflow.com/questions/4957514/how-to-compare-debian-package-versions .

So, it would be nice that cve-check-tool would:

• support matching to previous and older releases from CPE data
• support NVD xml data from version 1.2.1
• support comparing vulnerable SW version from NVD to the version in the analysis

This systemd use case is a simple test for that and cve-check-tool should detect that systemd 232 is vulnerable to CVE-2017-1000082.

[pkolbus]

I would like to see this as well, so I’ve been poking around a bit. The version relation is also in the new JSON 1.0 feeds. But more importantly, NIST plans for the XML feeds to go away around April 2019.