我正在使用 log4j 1.2.16。我将它与 maven selenium testng java 项目一起使用。我正在寻找不升级log4j版本的解决方案。
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
【问题讨论】：
另一个答案不正确。版本 1.x 也存在漏洞。 CVE-2021-4104 https://access.redhat.com/security/cve/CVE-2021-4104:
在 1.x 版的 Java 日志库 Apache Log4j 中发现了一个缺陷。 Log4j 1.x 中的 JMSAppender 容易受到不受信任数据的反序列化。如果部署的应用程序配置为使用 JMSAppender 和攻击者的 JMS 代理，这允许远程攻击者在服务器上执行代码。
为了缓解这个漏洞：
这些是针对 1.x 版本的此缺陷的可能缓解措施：
zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
【讨论】：
由于您使用的是 log4j 1，因此specific vulnerability 不存在。但是，请注意来自http://slf4j.org/log4shell.html 的以下内容：
log4j 1.x 是否易受攻击？ 鉴于 log4j 版本 1.x 的部署仍然非常广泛，可能是 log4j 2.x 的 10 倍，我们一直在收到关于 log4j 版本 1.x 漏洞的源源不断的问题。
由于 log4j 1.x 不提供消息级别的 JNDI 查找机制，因此它不会受到 CVE-2021-44228 的影响。
然而，log4j 1.x 带有
JMSAppender，如果在 log4j 的配置文件中启用，它将执行 JNDI 查找，即 log4j.properties 或 log4j.xml。已经对 log4j 配置文件具有写入权限的攻击者需要将
JMSAppender添加到被恶意连接参数毒化的配置中。请注意，之前对JMSAppender的合法使用与攻击者成功发起攻击的能力无关。还要注意毒化配置文件是不够的。攻击者还需要强制 log4j 重新加载带有中毒参数的配置文件。鉴于 log4j 1.x 不提供自动重新加载，中毒的配置文件通常只会在应用程序重新启动时生效。
尽管如此，虽然不容易，但这样的攻击并非不可能。因此，通过从 log4j-1.2.17.jar 中完全删除
JMSAppender来使攻击者的工作更加困难是有意义的。在没有新的 log4j 1.x 版本的情况下，您可以自己从 log4j-1.2.17.jar 工件中删除
JMSAppender。这是命令：zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class如果你无权使用'zip'，你也可以使用'jar'命令。
#assuming log4j-1.2.17.jar exists in current directory mkdir tmp cd tmp jar xvf ../log4j-1.2.17.jar rm org/apache/log4j/net/JMSAppender.class jar cvf ../log4j-1.2.17-patched.jar .不用说，一旦 log4j-1.2.17.jar 被打补丁，你就需要部署它。
【讨论】：