Log4j 2 庫中也發現了另一個漏洞 (CVE-2021-45105)，與前兩個問題不同，該漏洞被歸類為危險漏洞，但並不嚴重。 新問題允許您導致拒絕服務，並在處理某些行時以循環和崩潰的形式表現出來。 該漏洞已在幾個小時前發布的 Log4j 2.17 版本中修復。 這個問題僅出現在使用 Java 8 的系統上，這一事實減輕了該漏洞的危險。
此漏洞影響使用上下文查詢（Context Lookup）（例如${ctx:var}）來決定日誌輸出格式的系統。 Log4j 版本從 2.0-alpha1 到 2.16.0 缺乏針對不受控制遞歸的保護，這使得攻擊者可以操縱替換中使用的值來引發循環，從而導致堆疊空間耗盡和崩潰。 特別是在替換「${${::-${::-$${::-j}}}}」等值時出現問題。
此外，值得注意的是，Blumira 的研究人員提出了一種攻擊不接受外部網路請求的易受攻擊的Java 應用程式的選項；例如，Java 應用程式的開發人員或使用者的系統可以透過這種方式受到攻擊。 該方法的本質是，如果用戶系統上存在易受攻擊的Java進程，僅接受來自本地主機的網路連接，或處理RMI請求（遠端方法調用，連接埠1099），則可以透過執行JavaScript程式碼來進行攻擊當當使用者在瀏覽器中開啟惡意頁面時。 在此類攻擊中，為了與 Java 應用程式的網路連接埠建立連接，需要使用 WebSocket API，與 HTTP 請求不同，WebSocket API 不受同源限制（WebSocket 還可以用於掃描本地網路連接埠）主機以確定可用的網路處理程序）。
同樣令人感興趣的是 Google 發布的評估與 Log4j 依賴項相關的庫的漏洞的結果。 據 Google 稱，該問題影響 Maven 中央儲存庫中所有軟體包的 8%。 特別是，透過直接和間接依賴關係與 Log35863j 關聯的 4 個 Java 套件存在漏洞。 同時，Log4j 僅在 17% 的情況下被用作直接的一級依賴，而在 83% 的受影響套件中，綁定是透過依賴 Log4j 的中間套件進行的，即第二級以上的成癮（21% - 第二級，12% - 第三級，14% - 第四級，26% - 第五級，6% - 第六級）。 修復漏洞的速度仍然有很多不足之處；漏洞被發現一周後，在 35863 個已識別的軟體包中，迄今為止只有 4620 個軟體包已修復該問題，即為 13%。
同時，美國網路安全和基礎設施保護局發布了一項緊急指令，要求聯邦機構識別受 Log4j 漏洞影響的資訊系統，並在 23 月 28 日之前安裝阻止該問題的更新。 23月XNUMX日之前，各組織必須報告其工作。 為了簡化問題系統的識別，我們準備了一份已確認存在漏洞的產品清單（該清單包括超過 XNUMX 個應用程式）。
來源： opennet.ru