how could we resolve the transitive provided dependencies in maven?

user_10468191 0
Viewed 865

On Dec 10, a severe vulnerability was found in log4j2(CVE-2021-44228), I was asked to detect all the log4j usages (both direct and transitive) in our projects(mostly maven projects). I found it is easy to detect if log4j2 was listed as direct dependencies. I can inspect them through mvn dependency:tree or mvn dependency:build-classpath. Like the tree shown below. I know this is also the method Eclipse Steady and OWASP are using.

my-company:my-app:v1.0
\- org.apache.logging.log4j:log4j-api:jar:2.13.3:compile

However, in some special cases, things are not that easy. For example, I have another project like this:

my-company:my-app2:v1.0
\- com.alibaba:druid:jar:1.2.8:compile

This looks pretty clean, right? But actually, log4j2 is listed as a "provided" dependency in druid 1.2.8. Check pom here. According to maven document, "provided" scope is not transitive, thus log4j is not listed in the tree.

But actually, it is there. I can find the function call of log4j inside this druid:1.2.8.

check here: log4j2 in druid

I also use soot to make sure this function is actually reachable.

According to this page, any string like ${jndi:ldap://example.com/a} can cause such a problem. So theoretically, druid:1.2.8 is infected.

the Actuall tree maybe like this

my-company:my-app2:v1.0
\- com.alibaba:druid:jar:1.2.8:compile
    \-org.apache.logging.log4j:log4j-core:jar:2.13.3:provided

Lets define the relationship between log4j and my-app2 as transitive "provided" dependency

Here is my question:

  1. Why doesn't maven list the transitive provided dependencies in the tree? Just for a better understanding of the dependency relationship.

  2. Without checking poms one by one manually, how could we resolve the transitive provided dependency?

maven dependencies log4j scope
1 Answers

Class and method resolution in java happens during runtime, the first time the class or method is referenced. If the code you linked is run without Logger or LogManager on the classpath this would result in an error being thrown. If it is not actually used, for example if it has to be manually configured somehow, then this is totally fine.

Note also that both Logger and LogManager are part of the log4j-api dependency, while the code affected by the vulnerability is in log4j-core. A dependency on log4j-api should be totally fine and there are projects like log4j-to-slf4j that implement this api and delegate actual logging to a different implementation.

user_1395950
Related