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.45k stars 1.28k forks source link

Transitive dependency versions getting conflated with parent dependencies (such as xstream -> mxparser) #3230

Closed volkert-fastned closed 3 years ago

volkert-fastned commented 3 years ago

Describe the bug Some new vulnerabilities were added to the database w.r.t. XStream versions earlier than 1.4.16. That's of course a good thing. However, even after updating the XStream dependency to version 1.4.16, the DependencyCheck Maven plugin keeps reporting a whole laundry list of vulnerabilities, all of which should have been fixed in XStream 1.4.1.6, and some of which were already fixed in earlier versions of XStream as well:

mxparser-1.2.1.jar (pkg:maven/io.github.x-stream/mxparser@1.2.1, cpe:2.3:a:xstream_project:xstream:1.2.1:*:*:*:*:*:*:*) : CVE-2013-7285, CVE-2016-3674, CVE-2017-7957, CVE-2020-26217, CVE-2020-26258, CVE-2020-26259, CVE-2021-21341, CVE-2021-21342, CVE-2021-21343, CVE-2021-21344, CVE-2021-21345, CVE-2021-21346, CVE-2021-21347, CVE-2021-21348, CVE-2021-21349, CVE-2021-21350, CVE-2021-21351

I've checked the descriptions/summaries of all of these listed CVEs in the NIST database, and all of them pertain only to XStream versions earlier than 1.4.16, and none of them appear to have anything to do with the transitive mxparser dependency.

For users of the DependencyCheck plugins who are googling for these specific CVEs, I'm listing and summarizing them below:

I've encountered this issue often. Apparently the regex that is being used to check the minimum version of a potentially vulnerable dependency is erroneously checking the version numbers of any of its transitive dependencies as well. Adding false positives to the suppression file works as a workaround, but since this issue has been occurring often, a lot of false positives have had to be added to the suppression file this way. It would be nice if the underlying issue could be resolved, since it would alleviate the maintenance burden of the suppression file by any developers making use of the DependencyCheck plugin.

Version of dependency-check used Tested with multiple versions of the plugin:

Log file I'll provide one on request.

To Reproduce Steps to reproduce the behavior:

  1. Run the Maven Dependency Check plugin on a Maven project that has the XStream dependency version 1.4.16. Specifically this dependency:

        <dependency>
        <groupId>com.thoughtworks.xstream</groupId>
        <artifactId>xstream</artifactId>
        <version>1.4.16</version>
    </dependency>

Expected behavior None of the vulnerabilities that have been mitigated in XStream 1.4.16 should be reported by the plugin.

Additional context a whole laundry list of vulnerabilities that have been mitigated in XStream 1.4.16 are erroneously reported by the plugin, incorrectly pointing at the transitive dependency mxparser-1.2.1.jar as the alleged culprit.

jeremylong commented 3 years ago

This is not uncommon. Take a second to read how ODC works. In general, users just create a suppression rule for the CPE.

jeremylong commented 3 years ago

Simple solution is to use a suppression file:

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
   <suppress>
      <notes><![CDATA[
      mxparser is not xtream.
      ]]></notes>
      <packageUrl regex="true">^pkg:maven/io\.github\.x\-stream/mxparser@.*$</packageUrl>
      <cpe>cpe:/a:xstream_project:xstream</cpe>
   </suppress>
</suppressions>
volkert-fastned commented 3 years ago

Thanks for the suggested suppression entry.

Is there really no smarter way to handle, this though?

Let's take a look at this again. Running mvn dependency:tree on my project, I see the following relationship between the (potentially vulnerable) parent dependency and the transitive dependency that triggered these vulnerability flags:

[INFO] +- com.thoughtworks.xstream:xstream:jar:1.4.16:compile
[INFO] |  \- io.github.x-stream:mxparser:jar:1.2.1:compile

Why is cpe:2.3:a:xstream_project:xstream:*:*:*:*:*:*:*:* matching the transitive dependency as well here? Is this simply a decision to err on the side of caution and flagging anything matching the name, regardless of whether it's part of the package name or the artifact name?

Thanks again for your help and patience in explaining. :slightly_smiling_face:

jeremylong commented 3 years ago

One thing to note - the core engine that identifies the CPEs does not currently have the dependency tree. Rather it just analyzes the files provided. This is so that multiple build systems and the command line interface can be supported.

volkert-fastned commented 3 years ago

Ah, I see. Thanks for clarifying that. I understand how you don't want to make the core engine or any of the plugins too clever with these things, since you want as little complexity as possible. :slightly_smiling_face:

Unfortunately, your suggested suppression didn't fix it, since it's now tripping on a different CPE: cpe:2.3:a:oracle:jdk:1.2.1:*:*:*:*:*:*:*. And this list of CVEs is even longer. :slightly_frowning_face:

All of these are old CVEs from 2013 or earlier, so they are almost certainly all false positives as well.

mxparser-1.2.1.jar (pkg:maven/io.github.x-stream/mxparser@1.2.1, cpe:2.3:a:oracle:jdk:1.2.1:*:*:*:*:*:*:*) : CVE-2010-1423, CVE-2011-3546, CVE-2011-3547, CVE-2011-3561, CVE-2012-0504, CVE-2012-0547, CVE-2012-0551, CVE-2012-1531, CVE-2012-1532, CVE-2012-1533, CVE-2012-1682, CVE-2012-1711, CVE-2012-1713, CVE-2012-1716, CVE-2012-1717, CVE-2012-1718, CVE-2012-1719, CVE-2012-1720, CVE-2012-1721, CVE-2012-1722, CVE-2012-1723, CVE-2012-1724, CVE-2012-1725, CVE-2012-1726, CVE-2012-2739, CVE-2012-3136, CVE-2012-3143, CVE-2012-3159, CVE-2012-3216, CVE-2012-4416, CVE-2012-4681, CVE-2012-5067, CVE-2012-5068, CVE-2012-5069, CVE-2012-5070, CVE-2012-5071, CVE-2012-5072, CVE-2012-5073, CVE-2012-5074, CVE-2012-5075, CVE-2012-5076, CVE-2012-5077, CVE-2012-5079, CVE-2012-5081, CVE-2012-5083, CVE-2012-5084, CVE-2012-5085, CVE-2012-5086, CVE-2012-5087, CVE-2012-5088, CVE-2012-5089, CVE-2012-5373, CVE-2013-0424, CVE-2013-0425, CVE-2013-0426, CVE-2013-0428, CVE-2013-0432, CVE-2013-0434, CVE-2013-0440, CVE-2013-0441, CVE-2013-0442, CVE-2013-0443, CVE-2013-0809, CVE-2013-1475, CVE-2013-1476, CVE-2013-1478, CVE-2013-1480, CVE-2013-1481, CVE-2013-1493, CVE-2013-1500, CVE-2013-1518, CVE-2013-1537, CVE-2013-1540, CVE-2013-1557, CVE-2013-1558, CVE-2013-1561, CVE-2013-1563, CVE-2013-1564, CVE-2013-1569, CVE-2013-1571, CVE-2013-2383, CVE-2013-2384, CVE-2013-2394, CVE-2013-2400, CVE-2013-2407, CVE-2013-2412, CVE-2013-2414, CVE-2013-2415, CVE-2013-2416, CVE-2013-2417, CVE-2013-2418, CVE-2013-2419, CVE-2013-2420, CVE-2013-2421, CVE-2013-2422, CVE-2013-2423, CVE-2013-2424, CVE-2013-2425, CVE-2013-2426, CVE-2013-2427, CVE-2013-2428, CVE-2013-2429, CVE-2013-2430, CVE-2013-2431, CVE-2013-2432, CVE-2013-2433, CVE-2013-2434, CVE-2013-2435, CVE-2013-2436, CVE-2013-2437, CVE-2013-2438, CVE-2013-2439, CVE-2013-2440, CVE-2013-2442, CVE-2013-2443, CVE-2013-2444, CVE-2013-2445, CVE-2013-2446, CVE-2013-2447, CVE-2013-2448, CVE-2013-2449, CVE-2013-2450, CVE-2013-2451, CVE-2013-2452, CVE-2013-2453, CVE-2013-2454, CVE-2013-2455, CVE-2013-2456, CVE-2013-2457, CVE-2013-2458, CVE-2013-2459, CVE-2013-2460, CVE-2013-2462, CVE-2013-2463, CVE-2013-2464, CVE-2013-2465, CVE-2013-2466, CVE-2013-2467, CVE-2013-2468, CVE-2013-2469, CVE-2013-2470, CVE-2013-2471, CVE-2013-2472, CVE-2013-2473, CVE-2013-3743, CVE-2013-3744, CVE-2013-3829, CVE-2013-4578, CVE-2013-5772, CVE-2013-5774, CVE-2013-5775, CVE-2013-5776, CVE-2013-5777, CVE-2013-5778, CVE-2013-5780, CVE-2013-5782, CVE-2013-5783, CVE-2013-5784, CVE-2013-5787, CVE-2013-5788, CVE-2013-5789, CVE-2013-5790, CVE-2013-5797, CVE-2013-5800, CVE-2013-5801, CVE-2013-5802, CVE-2013-5803, CVE-2013-5804, CVE-2013-5805, CVE-2013-5806, CVE-2013-5809, CVE-2013-5810, CVE-2013-5812, CVE-2013-5814, CVE-2013-5817, CVE-2013-5818, CVE-2013-5819, CVE-2013-5820, CVE-2013-5823, CVE-2013-5824, CVE-2013-5825, CVE-2013-5829, CVE-2013-5830, CVE-2013-5831, CVE-2013-5832, CVE-2013-5838, CVE-2013-5840, CVE-2013-5842, CVE-2013-5843, CVE-2013-5844, CVE-2013-5846, CVE-2013-5848, CVE-2013-5849, CVE-2013-5850, CVE-2013-5851, CVE-2013-5852, CVE-2013-5854
volkert-fastned commented 3 years ago

@jeremylong So in addition to the suppression that you suggested, I added the following one as well, and that finally shut it up:

    <suppress>
        <notes><![CDATA[
      mxparser is not Oracle JDK.
      ]]></notes>
        <packageUrl regex="true">^pkg:maven/io\.github\.x\-stream/mxparser@.*$</packageUrl>
        <cpe>cpe:/a:oracle:jdk</cpe>
    </suppress>

It's still weird how your suppression suddenly triggered this false positive, though. Anyway, you might want to add this suppression to 6.1.4 as well. Thanks again. :slightly_smiling_face: