search

jeremylong / DependencyCheck

OWASP dependency-check is a software composition analysis utility that detects publicly disclosed vulnerabilities in application dependencies.
https://owasp.org/www-project-dependency-check/
Apache License 2.0
6.44k stars 1.28k forks source link

CPE matching takes over parent JAR version for embedded JARs #4064

Closed cedric-c84-eu closed 2 years ago

cedric-c84-eu commented 2 years ago

Describe the bug If a JAR embeds another non-exploded JAR (e.g. jackson-databind in version 2.13.1), the Dependency Check reports: myjar-1.0.0-20220211121548_4_c665335.jar (pkg:maven/de.kisters/myjar@1.0.0-20220211121548_4_c665335, cpe:2.3:a:fasterxml:jackson-databind:1.0.0:*:*:*:*:*:*:*) : CVE-2018-7489 It seems the check takes over the parent JAR version (1.0.0) for the CPE match, which should instead of be 2.13.1 and therefore -according to the CVE - not fail at all.

Version of dependency-check used The problem occurs using version 6.5.3 of the Maven plugin.

Log file https://gist.github.com/cedric-c84-eu/161054f7ce803f41e5524391d7c61f28

Screenshot_2022-02-11_15-18-04

aikebah commented 2 years ago

embedded jars are not exactly a standard feature of the Java Virtual Machine, so I would rather consider this an enhancement request (support embedded jars) than a bug.

aikebah commented 2 years ago

Note that it reports jackson-databind 1.0.0 for YOUR jar, not for the embedded jar (which it doesn't recognize as a dependency of its own)

aikebah commented 2 years ago

Looking closer at your logs... the nested dependency is already found and supported.

The false-positive that you get is merely a side-effect of how the tool works, combined with your own library likely not having registered CVEs and therefor being unknown as a CPE and all the evidences collected for it likely containing multiple references to the jackson libraries.

The nested jackson library:

[DEBUG] Begin Analysis of '/tmp/dctemp40e8a0a4-2f35-4a75-b947-318fc18c95ae/check191116520203681620tmp/3/lib/jackson-databind-2.13.1.jar' (NVD CVE Analyzer)
[DEBUG] Cache miss for cpe:2.3:a:fasterxml:jackson-databind:2.13.1:*:*:*:*:*:*:*

Your jar-file:

[DEBUG] Begin Analysis of '/home/user/dev/repository/m2/de/kisters/myjar/1.0.0-20220211121548_4_c665335/myjar-1.0.0-20220211121548_4_c665335.jar' (NVD CVE Analyzer)
[DEBUG] Cache miss for cpe:2.3:a:fasterxml:jackson-databind:1.0.0:*:*:*:*:*:*:*

Without more info from your side on the evidences found for YOUR library it would be hard to say whether there is anything we can do to improve the false-positive matching rate.

jeremylong commented 2 years ago

If the mismatch is on one of your libraries - like many others, one can simply use a suppression file during your scan.

cedric-c84-eu commented 2 years ago

embedded jars are not exactly a standard feature of the Java Virtual Machine, so I would rather consider this an enhancement request (support embedded jars) than a bug.

Agree. The problem is that we make heavy usage of the OSGi Framework where embedding JARs is a common pattern.

Without more info from your side on the evidences found for YOUR library it would be hard to say whether there is anything we can do to improve the false-positive matching rate.

Could you explain me what exactly do you mean by "evidences found for YOUR library"? I could provide a full log but I'm not sure this is what you expect.

If the mismatch is on one of your libraries - like many others, one can simply use a suppression file during your scan.

We actually use that as a workaround, but some enhancements to the plugin to support such usage would be nice to see too - even if the OSGi community isn't the largest one :-).

cedric-c84-eu commented 2 years ago

@aikebah hope this is what you are asking for: image image

aikebah commented 2 years ago

@cedric-c84-eu That's indeed the information I was looking for. And based on the information listed I see potential to remove these false positives towards the future. As DependencyCheck already analyzes the embedded jars themselves I see no reason to keep the embedded-artifacts entry of the Manifest of your main artifact as an evidence for the matching logic that attempts to match a library with known CPEs. And from the looks of the evidences that's the only evidence directly pointing towards jackson in your evidences.

aikebah commented 2 years ago

@cedric-c84-eu Would you be able to build a custom 7.0.0-SNAPSHOT version from the issue-4064 branch and run it on your project to validate my assumption that ignoring the embedded-artifacts entry of the Manifest will resolve your false positive?

cedric-c84-eu commented 2 years ago

@aikebah Just played around with the last release vs. local 7.0.0-SNAPSHOT, and it seems your change fixed our issue, perfect!