我正在使用 log4j 1.2.16。我在 maven selenium testng java 專案中使用它。我正在尋找不升級 log4j 版本的解決方案。
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
uj5u.com熱心網友回復：
另一個答案是不正確的。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 Broker，這將允許遠程攻擊者在服務器上執行代碼。
為了緩解此漏洞：
這些是版本 1.x 中針對此缺陷的可能緩解措施：
- 如果使用的話，在 Log4j 配置中注釋掉或移除 JMSAppender
- 從類路徑中洗掉 JMSAppender 類。例如：
zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
- 限制作業系統用戶在運行應用程式的平臺上的訪問，以防止攻擊者修改 Log4j 配置。
uj5u.com熱心網友回復：
由于您使用的是 log4j 1，因此此處不存在特定漏洞。但是，請注意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 的影響。
但是，
JMSAppender如果在 log4j 的組態檔中啟用，log4j 1.x將執行 JNDI 查找，即log4j.properties或log4j.xml。已經對 log4j 組態檔具有寫訪問權限的攻擊者將需要添加
JMSAppender到帶有惡意連接引數的配置中。請注意，先前的合法使用JMSAppender與攻擊者發起成功攻擊的能力無關。還要注意，毒害組態檔是不夠的。攻擊者還需要強制 log4j 使用中毒引數重新加載其組態檔。鑒于 log4j 1.x 不提供自動重新加載，中毒的組態檔通常只會在應用程式重新啟動時生效。
然而，雖然不容易，但這種攻擊并非不可能。因此，通過
JMSAppender從 log4j-1.2.17.jar 中完全洗掉來使攻擊者的作業更加困難是有道理的。如果沒有新的 log4j 1.x 版本，您可以
JMSAppender自己從 log4j-1.2.17.jar 工件中洗掉。這是命令：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 打上補丁，您就需要部署它。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/386420.html
上一篇：log4j漏洞檢查：如何快速檢測是否在mavevn/影像中使用了log4j？“mvndependency:tree”沒有給出完整的畫面