好的，這是我的問題：
- 如何輸出您的服務/應用程式的完整依賴樹，并找出是否在某個角落使用了 log4j？考慮到
mvn dependency:tree不允許您遍歷到底部的底部。檢查這個：當我mvn dependency:tree在我的 pom.xml 上做的時候，它給出了這樣的東西：
[INFO] | | - io.quarkus:quarkus-core:jar:2.4.1.Final:compile
[INFO] | | | - jakarta.enterprise:jakarta.enterprise.cdi-api:jar:2.0.2:compile
[INFO] | | | | \- jakarta.el:jakarta.el-api:jar:3.0.3:compile
[INFO] | | | - jakarta.inject:jakarta.inject-api:jar:1.0:compile
[INFO] | | | - io.quarkus:quarkus-ide-launcher:jar:2.4.1.Final:compile
[INFO] | | | - io.quarkus:quarkus-development-mode-spi:jar:2.4.1.Final:compile
[INFO] | | | - org.jboss.logging:jboss-logging:jar:3.4.2.Final:compile
[INFO] | | | - org.jboss.logmanager:jboss-logmanager-embedded:jar:1.0.9:compile
[INFO] | | | - org.jboss.logging:jboss-logging-annotations:jar:2.2.1.Final:compile
[INFO] | | | - org.jboss.threads:jboss-threads:jar:3.4.2.Final:compile
[INFO] | | | - org.jboss.slf4j:slf4j-jboss-logmanager:jar:1.1.0.Final:compile
[INFO] | | | - org.graalvm.sdk:graal-sdk:jar:21.2.0:compile
現在我明白了，這 -和\-用來代替├和└某種方式（但直到5分鐘前，我感到十分困惑），所以它們不是“不擴大”。但是，如果某些依賴項的 pom 使用 log4j，我不做任何事情就安全嗎？例如，當我檢查org.jboss.logging:jboss-logging:jar:3.4.2.Final:compile在https://search.maven.org/artifact/org.jboss.logging/jboss-logging/3.4.2.Final/jar，我看到org.apache.logging.log4j:log4j-core:2.11被使用，但那么它后來排除。所以我知道 Quarkus 是安全的。但是，我是否必須檢查我在依賴樹中找到的每個 jar 的 pom 以找出使用的和不使用的？
- 如果我從某個地方使用基本影像，我該如何在步驟 1 中執行此程序？我怎么知道我的基礎鏡像是易受攻擊的，因為它在依賴樹的某個角落使用了 log4j2 < 2.15？
這里有一些背景：https : //nvd.nist.gov/vuln/detail/CVE-2021-44228
編輯：現在我認為也許設定 env var 更好，所以它會一勞永逸地解決它。
uj5u.com熱心網友回復：
那么我們面臨的情況是，我們正在構建一個foo基于 Red Hat JBoss AMQ 6的應用程式。使用 jib maven 插件，我們的代碼將被構建到一個 uber jar 中并放在下面/opt/xxx執行，并且基本映像將放在其他罐子放入下圖/opt/amq/lib。
步驟1
對于我們的代碼，我們這樣做：
mvn dependency:tree | grep log4j
我們發現其他團隊的一些 dep 帶來了可傳遞的 log4j 1.17 左右。另一個團隊會處理它；在此之前，作為一種解決方法，我們將在我們的內部工件中手動從 jar 中洗掉JMSAppender.class和SocketServer.class，以便從那里下載的每個 jar 都將缺少類檔案。
第2步
在包含 log4j 的基礎映像中查找其他庫更為復雜。我必須首先找出影像中的內容。我先把docker save官方的 amq63 for Openshift 鏡像打包成 tarball；然后，我提取 jar 并使用grep.
docker save <image-name> -o amq63.tar
解壓tar，進入每一層的檔案夾，使用這個腳本：
#!/bin/bash
for f in $(find . -name "*.jar"); do
echo $f
jar -tvf $f | grep -E "(*JMSAppender*.class|*SocketServer.class|*log4j*.class)"
if [[ $? -eq 0 ]]; then
# only uncomment these lines after confirmation!
#echo Removing class file from $f
#zip -d $f "*JMSAppender.class" "*SocketServer.class" "*SimpleSocketServer.class"
fi
done
檢查發現的一些jar包，也有可能受到漏洞的影響。也許也JMSAppender.class應該從那里移除。我發現 jib maven 插件可以從本地tar檔案中加載影像，例如tar://path/to/file.tar，因此我們可以修改影像 taramq63.tar并再次構建。所以，如果它在target，把它像tar://target/amq63.tar。如果是絕對路徑，則為：tar:///home/me/amq63.tar。
此外，我們也應該更改組態檔的訪問權限，使其為只讀。
編輯：并且，如果您想從正在運行的 pod 中編輯 jar，它將不起作用，因為您需要重新啟動以再次加載類檔案，但無法重新啟動 pod；它們是不可變的；配置映射更改將持續存在，但 pod 中的狀態不會。
uj5u.com熱心網友回復：
請記住始終從下面列出的資源中檢查最新資訊
直接回答問題：
在代碼中檢查Log4J依賴項：
- 我認為 WesternGun 的答案很好......但我個人認為最簡單的方法可能是構建您的應用程式（如果您還沒有），然后遞回搜索構建的應用程式的目錄結構以查找與 REGEX 匹配的 JAR 檔案
log4j-core-2.([0-9] \.){1,2}jar（將檢測易受CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105 影響的版本）。如果您還想檢測舊版本（它們有自己的嚴重 CVE 并且也需要升級），那么 REGEX 就是這樣log4j，您必須手動找出哪些特定的 jar 是易受攻擊的。- 它實際上可能可以進一步改進......但我不確定特定的jar 檔案是這些其他 CVE 的問題：CVE-2019-17571和CVE-2021-4104
- Reddit 帖子：log4j_0day_being_exploited cntl ffor
.class and .jar recursive hunter將為您提供一些工具來幫助您進行遞回搜索
在運行應用程式時檢測 Log4J 的使用（在容器中與否無關緊要）：
- 轉到Reddit 執行緒：log4j_0day_being_exploited和cntl ffor
Vendor Advisories。在那里搜索您正在運行的任何軟體/插件的串列。如果您正在運行串列中的某些內容并且有可用更新，請更新。 - 然后去同一個網站和cntl f的
Vulnerability Detection。使用那里的工具。如果您檢測到漏洞，請進行修復。 - 然后去同一個網站和cntl f的
Exploitation Detection。使用那里的工具。這些將檢測您是否已經受到攻擊。如果您檢測到有，則根據需要進行補救并回應該攻擊。
更多資源
- https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
- 這個有很多有用的資訊，包括檢測器、更多的資源鏈接、非常容易理解的修復步驟等等
- https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
- https://github.com/cisagov/log4j-affected-db
- https://logging.apache.org/log4j/2.x/security.html
補救措施：
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
雖然大多數需要了解的人可能已經足夠了解他們需要做的事情，但我想我還是會把它放在以防萬一...
- 遵循這些資源中的指導......它可能會改變，但是
截至 2021-12-18
基本上是
- 如果可能，洗掉 log4j-core JAR 檔案
- 從兩臺跑步機立即修復和
- 在您的源代碼/源代碼管理檔案中，以防止未來的構建/發布/部署覆寫更改
- 如果這是不可能的（由于依賴性），請升級它們
- 如果你運行的是 Java8，那么你可以升級到 log4j 2.17.0
- 如果您運行的是較早版本的 Java，則可以升級到 log4j 2.12.3
- 如果您運行的是舊版本的Java，那么您需要升級到最新版本的Java，然后使用最新版本的Log4J
- 同樣，這些更改必須同時發生在運行機器和代碼中
- 如果由于某種原因這兩種方法都不可能......那么就存在從 log4j 核心 JAR 中洗掉 JndiLookup.class 檔案的非修復止損。
zip默認情況下，使用大多數 Linux 發行版打包的命令在 Linux 上有一個單行停止間隙選項。zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
- 在撰寫本文時，大多數 Windows 上停止間隙選項的在線指南都說要執行以下操作（再次...假設您無法執行上述洗掉 JAR 或升級選項之一）：
- 安裝類似 7-zip 的東西
- 找到所有 log4j-core JAR 檔案，并對每個檔案執行以下操作...
- 重命名 JAR 以將擴展名更改為
.zip - 使用 7-zip 解壓縮 JAR（現在有
.zip擴展名） - 在解壓后的檔案夾中找到并洗掉 JndiLookup.class 檔案
- 路徑是
\\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
- 路徑是
- 洗掉舊的 JAR 檔案（現在擴展名為 .zip）
- 使用 7-zip 重新壓縮檔案夾
- 重命名新的 .zip 檔案夾以將擴展名更改為
.jar
- 還有一些選項可以使用 Power Shell
- Reddit 執行緒：log4j_0day_being_exploited
- ctrl f代表“PowerShell”
如果您只有 1 或 2 個 JAR 檔案需要處理并且您不介意安裝 7-zip 或者您有可用的 PowerShell 來執行此操作，那么這很好。但是，如果您有大量 JAR 檔案，或者您不想安裝 7-zip 并且無法訪問 Power Shell，我創建了一個開源 VBS 腳本，無需安裝即可為您完成任何附加軟體。https://github.com/CrazyKidJack/Windowslog4jClassRemover
閱讀自述檔案和發行說明https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/386419.html
上一篇：無法找到log4jjar父依賴項