Incorrect parsing of CVE affected versions

[geekman]

According to the affected versions of CVE-2009-0590, the last entry at the end says "Up to (including) 0.9.8j", but the imported data into the cve_range table has a first entry that matches everything.

This causes the tool to incorrectly flag later versions of OpenSSL (like 1.0.1) as vulnerable.

select * from cve_range where cve_number = 'CVE-2009-0590';

           cve_number = CVE-2009-0590
               vendor = openssl
              product = openssl
              version = *
versionStartIncluding = 
versionStartExcluding = 
  versionEndIncluding = 
  versionEndExcluding = 

           cve_number = CVE-2009-0590
               vendor = openssl
              product = openssl
              version = 0.9.1c
versionStartIncluding = 
versionStartExcluding = 
  versionEndIncluding = 
  versionEndExcluding = 

    . . . 

           cve_number = CVE-2009-0590
               vendor = openssl
              product = openssl
              version = 0.9.8i
versionStartIncluding = 
versionStartExcluding = 
  versionEndIncluding = 
  versionEndExcluding = 

           cve_number = CVE-2009-0590
               vendor = openssl
              product = openssl
              version = *
versionStartIncluding = 
versionStartExcluding = 
  versionEndIncluding = 0.9.8j
  versionEndExcluding =

To reproduce (using CSV2CVE):

$ echo -e "product,vendor,version\nopenssl,openssl,1.0.1" > /tmp/cvefile
$ csv2cve /tmp/cvefile

Note that CVE-2009-0590 is listed in the output table of vulnerabilities.

[Niraj-Kamdar]

This seems to be originating from get_cves method of CVEDB class from cvedb module.

[terriko]

Quick check on the db says we've got a lot of these cases. My guess as to what's happening is that this is a parent node for a bunch of ranges. I could probably quick fix the code to make it such that anything that was * with no range info doesn't get added, but I'm not sure if that then destroys the case where a * could mean "all versions are affected, there is no known fix"

[terriko]

Yup, looking at CVE-2020-8478 (an arbitrary recent vuln with that pattern), we do have some cases where the * means probably everything.

But actually, it turns out I was wrong in my intution about the problem. The problem with CVE-2009-0590 is actually right here:

        "cpe_match" : [ {
          "vulnerable" : true,
          "cpe23Uri" : "cpe:2.3:a:openssl:openssl:*:*:openvms:*:*:*:*:*"
        },

Which is a line that says all versions of openssl on openvms are vulnerable. We're discarding that platform information because we don't know what platform might be involved (e.g. cve-bin-tool might be being used on a download server that runs on linux but hosts binaries for windows, and we'd want it to detect windows vulnerabilities).

So... I'm not sure we're doing the wrong thing with the data here, but I'm not sure the data is right either? I'd have to do some digging, but I'm guessing that entry I've quoted above is missing a "versionEndIncluding" : "0.9.8j" line and we should report it to NVD to fix is in their databases.

[terriko]

@pdxjohnny do you remember if we just email nvd or if they have a web form they'd prefer we use to ask about potential data mistakes?

[terriko]

Plan: we're going to report this issue to NVD. Short-term, you can use a triage file to ignore this particular CVE (and maybe we should make it part of a default triage file in the examples?)

[terriko]

There's nothing else we can do to resolve this, so I'm going to go ahead and close it.