identifying false positives

[Arbi Sookazian]

We are currently using dependency-check maven plugin version 1.4.5.

Doing some QA and false positive testing for the dependency check results for our projects' maven artifacts.

I changed our version of tomcat to 9.0.0.M22 in master pom.xml and ran the dependency/CVE analysis with this plugin.

For tomcat-api-9.0.0.M22.jar, for example, there are vulnerabilities listed which do not include M22 in the vulnerableSoftware version range.

Specifically, CVE-2017-5664, CVE-2017-5651, CVE-2017-5650 as examples.

Also, the following query against local H2 NVD db, I get no results.

SELECT ID, CPE, VENDOR, PRODUCT FROM CPEENTRY where CPE like 'cpe:/a:apache:tomcat:9.0.0:m22';

Please explain this as this seems to be a false positive in the CVE analysis results.  thanks.

Also, is the purpose of the <vulnerableSoftware> list of versions to indicate explicitly which versions of specific artifact needs to be id'd for CVE?

[Jeremy Long]

At the moment, dependency-check is only checking the version portion of the CPE identifier (https://cpe.mitre.org/specification/). So the update field (containing the m22) is not currently being evaluated. This should likely be added as an enhancement request to the github repo.

You can create suppression rules to remove these from the generated report.

--Jeremy

[Arbi Sookazian]

Here's another potential false positive.  I upgraded to 6.0.6 of mysql in our root/parent pom.  The results I'm seeing in dependency-check-report.xml show 3 CVEs but the descriptions are specific for a range of versions of mysql which doesn't include 6.0.6.  Please explain why these CVEs are included for this artifact.

Please see attache .xml file. thanks.

[Arbi Sookazian]

Also, the following query against local H2 DB gives no results:

SELECT ID, CPE, VENDOR, PRODUCT FROM CPEENTRY where CPE like '%mysql%6.0.6';

[Hans Aikema]

On 31 Jul 2017, at 19:00, Arbi Sookazian <asook...@gmail.com> wrote:

Here's another potential false positive.  I upgraded to 6.0.6 of mysql in our root/parent pom.  The results I'm seeing in dependency-check-report.xml show 3 CVEs but the descriptions are specific for a range of versions of mysql which doesn't include 6.0.6.  Please explain why these CVEs are included for this artifact.

Arbi, the reason is for all cases the data at the NVD of NIST. 

For CVE-2014-0001 an extended version of my findings then a quick summary for the rest….

Within the XML-report:

                    <vulnerableSoftware>
                        <software allPreviousVersion="true">cpe:/a:mariadb:mariadb:5.5.34</software>
                        <software>cpe:/a:mysql:mysql</software>
                    </vulnerableSoftware>

This is identical to what can be seen at the website of the NIST NVD itself:

https://nvd.nist.gov/vuln/detail/CVE-2014-0001

Where mariadb has a ‘last vulnerable version' listed and mysql is listed with wildcard version info, which is another way of documenting ‘to the best of our knowledge this vulnerability applies to all (past, current and future) mysql versions’. Given the NVD entry for CVE-2014-0001 flagging mysql 6.0.6 as vulnerable is the proper behavior for DependencyCheck. 

The entry in the NIST NVD database is however faulty as can be seen on https://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html where it is indicated that "CVE-2014-2440 is equivalent to CVE-2014-0001", which means that for CVE-2014-0001 the affected software for MySQL should match the list at https://nvd.nist.gov/vuln/detail/CVE-2014-2440). Something NIST has to fix in the NVD database which will then be automatically picked up by DependencyCheck on the next NIST NVD database update check.

CVE-2012-5627 - again listed for mysql without version numbers by NIST NVD

https://nvd.nist.gov/vuln/detail/CVE-2012-5627

Status for mysql is unclear to me; on fedora bugtracker it looks like Oracle won’t fix it and Redhat did not consider it sufficiently serious to create a patch themselves (https://bugzilla.redhat.com/show_bug.cgi?id=883719) searching for an Oracle CPU statement with this CVE yields no results. In the wording of the issue description however it appears as if both mysql and mariadb have been fixed for this issue

CVE-2008-4098 - alongside specific versions they still left the wildcard version as well, so according to the data in the NVD ‘in addtion to the specifically mentioned versions all other versions of mysql are also vulnerable'

https://nvd.nist.gov/vuln/detail/CVE-2008-4098

No Oracle CPU entry that I could find for this one, but could find listings at "https://linux.oracle.com/pls/apex/f?p=130:21:::NO:RP::” (search for CVE-2008-4098) that indicate that it was patched and this issue is present only for the versions of MySql prior to 5.0.67 (which corresponds with the last item in NIST NVD’s list: "cpe:2.3:a:mysql:mysql:5.0.51b:*:*:*:*:*:*:* and previous versions")

CVE-2008-0226 - again listed for mysql without version numbers by NIST NVD

https://nvd.nist.gov/vuln/detail/CVE-2008-0226

issue appears to be fixed in 5.0.67 / 5.1.23 as can still be found on the archived releasenotes

- http://ftp.nchu.edu.tw/MySQL/doc/refman/5.0/en/news-5-0-67.html

- http://ftp.nchu.edu.tw/MySQL/doc/refman/5.1/en/news-5-1-23.html

So end-result: all appear to be FPs caused by outdated metadata on the CVEs in the NIST NVD. Until NIST updates their database to correctly list the affected versions of MySQL you can suppress them with a suppression file.

CC-ing NIST NVD to notify them of these errors in their data

regards,

Hans

[Arbi Sookazian]

Thanks Hans.

[Arbi Sookazian]

How often is the NVD updated?

The NVD is updated whenever a new vulnerability is added to the CVE dictionary of vulnerabilities. The vulnerabilities are then analyzed by NVD analysts and augmented with vulnerability attributes (e.g. vulnerable versions) within two-business days excluding Federal Holidays.

https://nvd.nist.gov/general/faq#d4865562-9756-43f4-8ae5-d481a89ca504

There is no mention of "false positives" in this web page.  So do we presume that they update/fix false positive data on an ad-hoc/manual basis?  thx.

[Jeremy Long]

The NVD data documents what versions are vulnerable. If the version you are using is not listed it is likely not vulnerable.

--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.