Dependencycheck: Vulnerable dependencies not found on shaded jars on some cases

Created on 12 Nov 2019  路  3Comments  路  Source: jeremylong/DependencyCheck

Describe the bug
My understanding is that JarAnalyzer extracts the pom.xml files of the shaded dependencies and analyze those (See this commit). I suspect that the issue is that some dependencies don't have pom.xml files (ie. commons-fileupload 1.0) and hence are not found.

* Version of dependency-check used *
dependency-check-maven version 5.2.3

To Reproduce
Steps to reproduce the behavior:

  1. Create a shaded jar using maven-shade-plugin (m1).
  2. Include the mentioned version of fileupload to m1.
  3. Import that dependency in an independent maven module (m2).
  4. Run dependency-check-maven plugin on m2.

Expected behavior
I expect commons-fileupload to be reported as a shaded vulnerable dependency but it is not reported at all. If I run the dependency-checker on the shaded module itself, it reports it successfully.

Please, let me know if you need more info.
Thank you for your work.

bug won't fix

Most helpful comment

Unfortunately - shaded jars represent a challenge. In the cases when the dependent library that is "shaded" contains a pom.xml in the META-INF directory (i.e. was built by maven or uses the maven plugin for gradle) - then we can extract information and detect the dependency. However, in the case of commons-fileupload they do not have a pom.xml in the META-INF (not entirely sure what build system they use). As such, dependency-check will not be able to identify the dependency. The situation is unfortunately rather bleak for shaded or uber jars (actually - its worse for uber jars). Even several of the commercial products have difficulty with this.

I wish I had a better solution for this - but the only thing I can come up with would be to create a couple of specific package rules that would be specific to apache and possible a few other common packages. But this could become a fairly arduous and likely unreliable maintenance task for this project.

All 3 comments

Unfortunately - shaded jars represent a challenge. In the cases when the dependent library that is "shaded" contains a pom.xml in the META-INF directory (i.e. was built by maven or uses the maven plugin for gradle) - then we can extract information and detect the dependency. However, in the case of commons-fileupload they do not have a pom.xml in the META-INF (not entirely sure what build system they use). As such, dependency-check will not be able to identify the dependency. The situation is unfortunately rather bleak for shaded or uber jars (actually - its worse for uber jars). Even several of the commercial products have difficulty with this.

I wish I had a better solution for this - but the only thing I can come up with would be to create a couple of specific package rules that would be specific to apache and possible a few other common packages. But this could become a fairly arduous and likely unreliable maintenance task for this project.

shade overlap introduces further complications

[WARNING] core-io-1.6.2.jar, jackson-core-2.10.2.jar define 3 overlapping resources: 
[WARNING]   - META-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.properties
[WARNING]   - META-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.xml
[WARNING]   - META-INF/services/com.fasterxml.jackson.core.JsonFactory
[WARNING] commons-codec-1.9.jar, commons-configuration-1.8.jar, commons-io-2.4.jar, commons-lang-2.6.jar, commons-lang3-3.7.jar define 2 overlapping resources: 
[WARNING]   - META-INF/LICENSE.txt
[WARNING]   - META-INF/NOTICE.txt
[WARNING] httpcore-4.4.4.jar, log4j-api-2.10.0.jar, log4j-core-2.8.2.jar, log4j-to-slf4j-2.10.0.jar, org.apache.commons.io-2.4.jar define 1 overlapping resource: 
[WARNING]   - META-INF/DEPENDENCIES
[WARNING] logback-classic-1.2.3.jar, slf4j-nop-1.6.1.jar define 3 overlapping classes: 
[WARNING]   - org.slf4j.impl.StaticLoggerBinder
[WARNING]   - org.slf4j.impl.StaticMDCBinder
[WARNING]   - org.slf4j.impl.StaticMarkerBinder
[WARNING] core-io-1.6.2.jar, jackson-databind-2.9.10.jar define 3 overlapping resources: 
[WARNING]   - META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.properties
[WARNING]   - META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.xml
[WARNING]   - META-INF/services/com.fasterxml.jackson.core.ObjectCodec
[WARNING] core-io-1.6.2.jar, jackson-annotations-2.9.10.jar define 2 overlapping resources: 
[WARNING]   - META-INF/maven/com.fasterxml.jackson.core/jackson-annotations/pom.properties
[WARNING]   - META-INF/maven/com.fasterxml.jackson.core/jackson-annotations/pom.xml
[WARNING] HdrHistogram-2.1.9.jar, core-io-1.6.2.jar define 2 overlapping resources: 
[WARNING]   - META-INF/maven/org.hdrhistogram/HdrHistogram/pom.properties
[WARNING]   - META-INF/maven/org.hdrhistogram/HdrHistogram/pom.xml
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/

pay attention to the pom.xml entries

also take a look at how relocation can obfuscate the inclusion of vulnerable classes
https://github.com/couchbase/couchbase-jvm-core/blob/1.6.2/pom.xml#L349-L352

Was this page helpful?
0 / 5 - 0 ratings