Log4j overslf4j易受log4shell攻击吗？

Question

在我的服务器上，我查看了所有包含log4j的文件，并且只有一个log4j-over-slf4j jar文件。

SLF4J关于log4shell的页面声明如下：

如果将log4j -over slf4j.jar与SLF4J API结合使用，则除非底层实现是log4j 2.x，否则是安全的。

不过，我觉得这很不清楚。我如何知道“基础实现”是否是log4j 2.x？

如果我没有在我的服务器上看到文件名中包含log4j的任何内容，这是否意味着我很好？

Answer 1

LOG4J -overslf4j只将日志记录调用从LOG4J API转换为SLF4J API。但是要真正创建日志条目，您需要一个实现SLF4J API的库，例如Logback。在这种情况下，应用程序代码认为日志记录是由LOG4J完成的，但实际上是由Logback完成的。它看起来如下：

your code -> LOG4J API -> log4j-over-slf4j -> Logback -> file (database, Splunk, Elastic Search, ...)

关于你的问题：

我如何知道“基础实现”是否是log4j 2.x？

如果您开发了所引用的应用程序，那么您必须知道如何在您的应用程序中实现日志记录，并且知道是否使用了特定的库。

如果您没有开发它，那么检查受影响的类是否包含在应用程序二进制文件中。在应用程序的所有文件中搜索"JndiLookup.class“，解压缩所有档案：.jar、.zip、.war、.ear等。如果您发现它不是在"log4j-core-2.*.jar”中，而是在"log4j-core.jar“中，甚至在”.jar“中(万一使用了”胖jar“)，请不要感到惊讶。如果文件存在，请查找其版本。那你就知道你是否有问题了。

如果应用程序使用标准库而不重新打包它们，例如不生成“胖jar"，那么所讨论的类包含在log4j-core.jar或log4j-core-.jar中。如果您不开发，也不知道结构，这里是源代码。如您所见，类"JndiLookup.class“包含在模块"log4j-core”中。

你写的只有"log4j-over-slf4j“。因此，您没有"log4j-core“，并且您的应用程序不受log4shell问题的影响。

Answer 2

答案是“否”，因为log4j-over-slf4j只提供log4j API，而不包含log4j的任何实现。

但是，有效地通过log4j-over-slf4j的存在，您无法得出任何关于服务器是否易受攻击的结论。

如果您找到属于log4j-over-slf4j的jar文件，这将提示您潜在地使用slf4j和logback作为日志记录服务。Logback是一个完全独立于log4j的不同的日志实现。

但实际上，一个服务器可以同时使用多个日志记录服务。因此，如果服务器是安全的，则必须搜索服务器中是否存在易受攻击的log4j代码，因此必须搜索属于导致漏洞的log4j的类。

检查现有产品是否包含(因此可能使用) log4j版本1.x或2.x的常见方法是执行Python Log4j-查找器。它在整个文件系统中搜索与log4j漏洞相关的类文件，并试图根据它们的散列(如果它们是否易受攻击)进行匹配。

这个工具的最大优点是还可以搜索JAR文件中的类文件，即使它们嵌套在另一个JAR文件中(还有EAR/WAR和所有其他打包格式)。这种嵌套的归档在Java中非常常见。

当然，log4j-finder并不完美，所以即使它没有找到任何与log4j相关的东西，这并不意味着您的服务器没有log4j。还有其他形式的打包，有时使用加密和其他混淆技术，这使得很难检测是否在二进制级别上使用log4j。因此，log4j-finder只给出程序不使用(或只在固定版本中使用) log4j的基本概率。

因此，最后，您应该始终与服务器的公司/开发人员联系，询问是否使用或不使用log4j以及在哪个版本中使用。