false positive still an issue in v6.5.0 ODC

[mushu999]

Still an issue in v6.5.0 of dependency checker...

Microsoft.DiaSymReader.Native.x86.dll File Path: C:...\bin\roslyn\Microsoft.DiaSymReader.Native.x86.dll MD5: 4ff7094e3edfda47ced912012044296b SHA1: c6f3c9d81713687dc3820d8cabf14c2a32208d27 SHA256:f21da9fb831ac943736135b6ee109a4b352511b8d6c07cb03c66b61996d1ddc9

Originally posted by @mushu999 in https://github.com/jeremylong/DependencyCheck/issues/2819#issuecomment-1009147902

[mushu999]

Also note that Microsoft has responded in this thread: https://developercommunity.visualstudio.com/t/Vulnerability-with-MicrosoftDiaSymReade/1400379

This appears to be a case of mistaken identity. I’m not familiar with this “OWASP Dependency Checker” tool, but when I run it against Microsoft.DiaSymReader.Native.*.dll, it does indeed report the above information, but CVE-2006-2480 was reported in 2006 against a component call “Dia,” which, as far as I can tell, is/was a part of Gnome, which runs/ran on Linux. It isn’t remotely (again, as far as I can tell) related to the Microsoft Debug Interface Access (“DIA”) SDK. I have no idea why the Dependency Checker tool thinks this CVE is related unless it’s because this analyzer: “[INFO] Finished File Name Analyzer (0 seconds)]” is unreliable.

[jeremylong]

As with #2819 I have been unable to reproduce. If you can provide a sample project we can look into the FP.

Also note - false positives are expected when running dependency-check. Most false positives can be resolved without wasting a vendors' time (like Microsoft). It is as simple as actually reading the CVE and looking through the references to figure out if something is a false positive. I would highly recommend reading:

1. How dependency-check works
2. How to read the report
3. Suppressing False Positives

[mushu999]

I didn't want to suppress those in case there was ever an update and it turned out there is a new vuln involving them. There shouldn't be a need to send you a project. Go into Visual Studio and create a new project, then just use DC to scan the source files. You will see it flag these files in the source location bin\roslyn

12/05/2017  08:36 AM         1,495,800 Microsoft.DiaSymReader.Native.amd64.dll
12/05/2017  08:36 AM         1,188,080 Microsoft.DiaSymReader.Native.x86.dll
               2 File(s)      2,683,880 bytes

These in particular are from VS2017 but I suspect VS2019 also will trigger this. The question I have is why these particular .dll's trigger the CVE if it is not a vuln involving them? I assumed the hashes are to ensure the particular files are checked against known CVE's in order to avoid FP's but if the CVE itself is flagging the wrong files then I guess I would understand.

If you like I can zip and attach those two files, just don't tell Microsoft in case they don't like it lol!

[pdenooijer]

It seems the dependency check does a fuzzy search on the dependencies instead of strictly checking the artifactId. I made an example project where it gives me the following false positives when I run mvn dependency-check:check:

camel-quarkus-core-2.6.0.jar (pkg:maven/org.apache.camel.quarkus/[email protected], cpe:2.3:a:apache:camel:2.6.0:*:*:*:*:*:*:*) : CVE-2013-4330, CVE-2014-0002, CVE-2014-0003, CVE-2015-0263, CVE-2015-0264, CVE-2015-5344, CVE-2015-5348, CVE-2017-12633, CVE-2017-12634, CVE-2017-3159, CVE-2017-5643, CVE-2019-0188, CVE-2019-0194
jakarta.el-api-3.0.3.jar (pkg:maven/jakarta.el/[email protected], cpe:2.3:a:eclipse:jakarta_expression_language:3.0.3:*:*:*:*:*:*:*) : CVE-2021-28170
quarkus-fs-util-0.0.3.jar (pkg:maven/io.quarkus/[email protected], cpe:2.3:a:quarkus:quarkus:0.0.3:*:*:*:*:*:*:*) : CVE-2017-18640, CVE-2019-14900, CVE-2020-10693, CVE-2020-13692, CVE-2020-13956, CVE-2020-1714, CVE-2020-1728, CVE-2020-25633, CVE-2020-25638, CVE-2020-25649, CVE-2020-25724, CVE-2020-8908, CVE-2021-20289, CVE-2021-20328, CVE-2021-21290, CVE-2021-21295, CVE-2021-26291, CVE-2021-28170, CVE-2021-29427, CVE-2021-29428, CVE-2021-29429, CVE-2021-3642, CVE-2021-37714

None of the above CVE are correct. camel-quarkus-core:2.6.0 matches with camel:2.6.0 which is a different package. jakarta.el-api:3.0.3 matches with jakarta.el:3.0.3. quarkus-fs-util:0.0.3 matches with quarkus:0.0.3.

According to sonatype:

• [email protected]
• [email protected]
• [email protected]

Hopefully this extra context helps 🙂.

[aikebah]

I didn't want to suppress those in case there was ever an update and it turned out there is a new vuln involving them.

You would not risk this if you suppress appropriately: suppress the exact vulnerability or the exact cpe for a sufficiently detailed filepattern. A new vulnerability will have a different vulnerability identifier and therefore not suppressed by vulnerability identifier suppression. When there is a vulnerability found in the DiaSymReader dll its CPE will be different and therefore not suppressed by a CPE suppression and if at some point someone adds a dependence on the true Dia library its filename should not match your well-chosen filename pattern and therefore the CVE or CPE would not get suppressed for it.

[brampat]

As I understand, matching java jars to NVD Vulns. is done by matching the CPE entries to package names, manifest file and pom.xml. Apparently this results in fuzzy matching with a confidence score. What's off, is that all vulns in @pdenooijer 's example is that 3 of 4 are scored Highest on confidence and only Jakarta el-api scores low on Confidence. I always thought matching of vulnerable jars could, should and was done by comparing hashes, but since NVD CVE's apparently don't supply hashes of jars / binaries. This has probably been discussed before by much smarter ppl, but why doesn't this work on hashes instead?

[jeremylong]

To match on hashes would require one to maintain a database of hash to CPE. There is no completely open source database that I know of that maps hashes to CPEs. Thus - we use an evidence based approach. See https://jeremylong.github.io/DependencyCheck/general/internals.html

[renegrob]

I have the same issue:

• quarkus-liquibase-2.8.2.Final.jar is matched as liquibase/liquibase prior to 4.8.0
• quarkus-spring-data-jpa-api-2.1.SP2.jar is matched as cpe:2.3:a:quarkus:quarkus:2.1:sp2:*:*:*:*:*:* but it is actually part of quarkus 2.8.2.Final and not of 2.1.SP2

-> It would be great if we could configure a more strict matching in the suppression.xml, respectively suppress the wrong match. E.g. configure that io.quarkus:quarkus-liquibase does not match liquibase:liquibase. Then real vulnerabilities of io.quarkus:quarkus-liquibase would still be reported while now I have to exclude it completely to avoid false positives.

[aikebah]

@renegrob you already can do things like that already with the CPE suppressions (using the CPE 2.2 format). Most suppressions are CPE suppressions. (though nowadays you would typically use packageUrl instead of gav)

[renegrob]

@aikebah Thank you, I finally figured it out and opened PR #4472

[brampat]

Another example of something that could be improved: we currently use the latest Spring-Boot Security (direct) dependency, which OWASP Dep.Check flags as vulnerable for CVE-2022-22976, which resides in spring-security-web and spring-security-core (both indirect dependencies through Spring-Boot Security) although in versions 5.6.3 and older. This is also clearly indicated in the CVE (from 5.6.0 incl to 5.6.4 excl.). OWASP Dep.Check however marks direct the 2.7.0 version as vulnerable evidence.

OWASP Dep.Check connects the wrong dots here:

• spring-security is not spring--boot-starter-security, although it depends on spring-security. OWASP Dep.Check incorrectly thinks this is spring-security instead of spring-boot-security-starter
• The version numbers are incorrectly compared, but since 2.7.0 (of spring-boot-starter-security) is in the vulnerable range of spring-security (up to 5.5.7 excl.) it is marked as vulnerable to this CVE. This false positive will remain an issue until spring-boot-starter-security lands on v5.5.7 and will continue through 5.6.0 until it arrives on 5.6.4

Is there any way we can help improve the detection of actual dependencies used vs. dependencies mentioned in CVE's? We discussed doing this hash-based, but feasibility is under discussion.

[aikebah]

@brampat please do not hijack this ticket for continuing discussions unrelated to the raised FP.