DependencyCheck
DependencyCheck copied to clipboard
[FP]: Multiple CVEs reported against camel-activemq
Package URl
pkg:maven/org.apache.camel/[email protected]
CPE
cpe:2.3:a:apache:activemq:3.18.0:*:*:*:*:*:*:*, cpe:2.3:a:apache:camel:3.18.0:*:*:*:*:*:*:*
CVE
Multiple
ODC Integration
{"label"=>"CLI"}
ODC Version
7.1.1
Description
This is a tricky one I think...
Apache Camel is an open source integration framework that empowers you to quickly and easily integrate various systems consuming or producing data.
- CVE-2016-3088 applies to ActiveMQ (server)
- CVE-2014-3576 applies to ActiveMQ (server)
- CVE-2018-11775 applies to the ActiveMQ client (org.apache.activemq activemq-client) but camel-activemq doesn't seem to be affected
- CVE-2010-1244 applies to ActiveMQ (server)
- CVE-2013-3060 applies to ActiveMQ (server)
- CVE-2020-13947 applies to ActiveMQ (server)
- CVE-2020-13920 applies to ActiveMQ (server)
- CVE-2012-5784 applies to the ActiveMQ client (perhaps activemq-client) but camel-activemq doesn't seem to be affected
- CVE-2011-4905 applies to ActiveMQ (server)
- CVE-2012-6551 applies to ActiveMQ (server)
- CVE-2015-7559 applies to the ActiveMQ client but camel-activemq doesn't seem affected
- CVE-2012-6092 applies to ActiveMQ (server)
- CVE-2013-1879 applies to ActiveMQ (server)
- CVE-2013-1880 applies to ActiveMQ (server)
- CVE-2010-0684 applies to ActiveMQ (server)
The dependency I include is [email protected] but I think all the above CVEs, when they refer to client side vulnerabilities, they apply to activemq-camel/client which from what I can see are still transitive dependencies but the version that is imported is 5.17.1 which should not be vulnerable according to the CPEs for each CVE.
So it looks there are multiple issues here at play:
- Both server and client CVEs are matched against the client
- CVEs that could apply to activemq-camel/client (which is on version 5.x.x) are flagged for camel-activemq (which is on version 3.x.x)
- If it is flagging these CVEs against the transitive dependency is matching those CVEs against the wrong version (e.g. I have 5.17.1 installed and CVE is for up to 5.6.0)
Maven Coordinates
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-activemq</artifactId>
<version>3.18.0</version>
</dependency>
Suppression rule:
<suppress base="true">
<notes><![CDATA[
FP per issue #4721
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.camel/camel-activemq@.*$</packageUrl>
<cpe>cpe:/a:apache:activemq</cpe>
</suppress>
Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/2777399716
Maven Coordinates
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-activemq</artifactId>
<version>3.18.0</version>
</dependency>
Suppression rule:
<suppress base="true">
<notes><![CDATA[
FP per issue #4721
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.camel/camel-activemq@.*$</packageUrl>
<cpe>cpe:/a:apache:activemq</cpe>
</suppress>
Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/2777400660
It's not as tricky as you think, dependency-check is well prepared to handle the case of activemq being a transtive dependency of a library falsely identified as being part of activemq.
The suppression as suggested (suppression of the apache activemq CPE on this library) is fully appropriate. The transitive dependencies towards activemq libraries will be found and assessed by dependency-check on their own merits (using the proper version of activemq (5.17.1) to evaluate against the vulnerable version range). If any CVEs still apply to ActiveMQ 5.17.1 they will be reported (dependency-check does distinguish between the client- and server-side of activeMQ, as there is only a single CPE for both within the NIST NVD, so server-side issues can be expected to be reported when only using the client-side libraries)
Hi @aikebah, thanks for the information.
Does this mean this can/should be put into a release? If so, when do you think this could be done?
Thanks
@mpreziuso yes, thanks for pinging me on this. Will try to get it in our hosted suppressions file.
approved
Suppress rule has been added to the generatedSuppressions branch.