[3.1.0] Issues with vulndb import

[Vít Šesták]

I've realized that https://nvd.nist.gov/vuln/detail/CVE-2015-5237 specifies range of vulnerable versions, but in local DB, there is versionless information. The history shows this has been changed recently (2/13/2018 1:33:51 PM).

[odc]> select * from cpeEntry where cpe like '%proto%buf%';
+--------+--------------------------+--------+----------+
| id     | cpe                      | vendor | product  |
+--------+--------------------------+--------+----------+
| 180699 | cpe:/a:google:protobuf:- | google | protobuf |
+--------+--------------------------+--------+----------+


So, this looks like some failure of DB update. I've tried to use a fresh H2 DB (rm data/* and then ./bin/dependency-check.sh --updateonly) to test if it imports correctly. It, however, does not import at all:


> select * from cpeEntry where cpe like '%proto%buf%';
no result

> select * from vulnerability where cve = 'CVE-2015-5237';
no result

> select count(*) from vulnerability limit 10;
returns 85609, which is quite more than on production…

What to do?

Regards,
Vít Šesták 'v6ak'

[Jeremy Long]

The problem is that the NVD XML data feed does not include the CPEs for this entry. The 2015 2.0 XML datafeed entry contains the below data - without the vulnerable configuration section being complete and containing the CPE we have no valid data.  I've emailed the NVD to see about getting this fixed.

<entry id="CVE-2015-5237">

<vuln:vulnerable-configuration id="http://nvd.nist.gov/">

<cpe-lang:logical-test operator="OR" negate="false"/>

</vuln:vulnerable-configuration>

<vuln:cve-id>CVE-2015-5237</vuln:cve-id>

<vuln:published-datetime>2017-09-25T13:29:00.397-04:00</vuln:published-datetime>

<vuln:last-modified-datetime>2018-02-13T13:33:51.727-05:00</vuln:last-modified-datetime>

<vuln:cvss>

<cvss:base_metrics>

<cvss:score>6.5</cvss:score>

<cvss:access-vector>NETWORK</cvss:access-vector>

<cvss:access-complexity>LOW</cvss:access-complexity>

<cvss:authentication>SINGLE_INSTANCE</cvss:authentication>

<cvss:confidentiality-impact>PARTIAL</cvss:confidentiality-impact>

<cvss:integrity-impact>PARTIAL</cvss:integrity-impact>

<cvss:availability-impact>PARTIAL</cvss:availability-impact>

<cvss:source>http://nvd.nist.gov</cvss:source>

<cvss:generated-on-datetime>2018-02-13T13:15:34.710-05:00</cvss:generated-on-datetime>

</cvss:base_metrics>

</vuln:cvss>

<vuln:cwe id="CWE-119"/>

<vuln:references xml:lang="en" reference_type="VENDOR_ADVISORY">

<vuln:source>MLIST</vuln:source>

<vuln:reference href="http://www.openwall.com/lists/oss-security/2015/08/27/2" xml:lang="en">[oss-security] 20150827 CVE-2015-5237: Integer overflow in protobuf serialization (currently minor)</vuln:reference>

</vuln:references>

<vuln:references xml:lang="en" reference_type="VENDOR_ADVISORY">

<vuln:source>CONFIRM</vuln:source>

<vuln:reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1256426" xml:lang="en">https://bugzilla.redhat.com/show_bug.cgi?id=1256426</vuln:reference>

</vuln:references>

<vuln:references xml:lang="en" reference_type="VENDOR_ADVISORY">

<vuln:source>CONFIRM</vuln:source>

<vuln:reference href="https://github.com/google/protobuf/issues/760" xml:lang="en">https://github.com/google/protobuf/issues/760</vuln:reference>

</vuln:references>

<vuln:summary>protobuf allows remote authenticated attackers to cause a heap-based buffer overflow.</vuln:summary>

</entry>

[Vít Šesták]

Thank you for the response.

I have an idea how to find some inconsistencies proactively. That's not a panacea, it would just find cases where update leads to a different state than loading it from clean state (which is also this case):

1. Maintain a regularly (daily?) updated vulndb.
2. Sometimes (weekly?), download and import the vulndb from scratch. Then compare it.

The hardest part is probably a proper comparison, because it is probably not guaranteed that it results in the same identifiers. However, given the number of tables, it does not look as a hard task.

Maybe this could even be used for testing of the new JSON feed import.

Do you think this might be useful?

Regards,
Vít Šesták 'v6ak'

[Vít Šesták]

I guess the original mail should have been sent to the group, not privately.

I am not sure where the problem comes from, but I see also a consistency problem: It initially came with no version. At the moment, there is no CPE. I however agree that consistency is _not the only_ problem here.

Regards,
Vít Šesták 'v6ak'

On March 24, 2018 1:44:28 PM GMT+01:00, Jeremy Long <jerem...@gmail.com> wrote:

Not sure if it is a consistency problem - but rather a data quality problem that you've run into.  Maybe we need to scan the data feeds and see how many items do not have the vulnerable software section.

--Jeremy

--
You received this message because you are subscribed to the Google Groups "Dependency Check" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dependency-check+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity.

[Jeremy Long]

I believe the issue lies on the data source side. If the data is not available ODC cannot parse it and import it.

--Jeremy