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 .
2条答案
按热度按时间1bqhqjot1#
另一个答案不正确。版本1.x. CVE-2021-4104 也存在漏洞:
在1.x版的Java日志库Apache Log4j中发现了一个缺陷。Log4j 1.x中的JMSAppender易受不受信任数据的反序列化攻击。如果部署的应用程序配置为使用JMSAppender和攻击者的JMS代理,则这使得远程攻击者能够在服务器上执行代码。
要缓解此漏洞,请执行以下操作:
以下是1.x版中此缺陷的可能缓解措施:
5m1hhzi42#
由于您使用的是Log4j 1,因此specific vulnerability不在此处。但是,请注意 * Comments on the log4shell(CVE-2021-44228) vulnerability * 中的以下内容:
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的配置文件(即 log4j.properties 或 log4j.xml)中启用了该JMSAppender
,它将执行JNDI查找。已经对log4j配置文件具有写访问权限的攻击者需要将
JMSAppender
添加到被恶意连接参数毒害的配置中。请注意,先前合法使用JMSAppender
与攻击者成功发起攻击的能力无关。另请注意,仅使配置文件中毒是不够的。攻击者还需要强制log4j使用中毒的参数重新加载其配置文件。由于log4j 1.x不提供自动重新加载,中毒的配置文件通常只有在应用程序重新启动时才生效。
然而,虽然这样的攻击并不容易,但也不是不可能的,因此,通过从log4j-1.2.17.jar中删除
JMSAppender
,使攻击者的工作变得更加困难是有意义的。如果没有新的log4j 1.x版本,您可以自己从log4j-1.2.17.jar工件中删除
JMSAppender
。如果您没有访问“zip”的权限,也可以使用“jar”命令。
不用说,一旦log4j-1.2.17.jar打了补丁,您就需要部署它。