大家好，我是明哥!

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

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

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

1 LOG4J 概述

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

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

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

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

正式由于以上諸多優(yōu)點(diǎn)，log4j 成為了 JAVA 生態(tài)中應(yīng)用最廣泛的日志框架。

2 LOG4J JNDI 系列漏洞概述

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

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

以上 JNDI 系列漏洞，LOG4J2 官方團(tuán)隊(duì)已經(jīng)修復(fù)，概括起來, 針對危險等級為 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 其實(shí)是 Java 在 1990 年之后引入的一種目錄服務(wù)，是 J2EE 的重要組成部分，讓 Java 程序可以以 Java 對象的形式通過目錄查找數(shù)據(jù)。JNDI 提供了多種 SPI 支持不同的目錄服務(wù)，如 CORBA COS (公共對象服務(wù))、Java RMI (遠(yuǎn)程方法接口) Registry 和 LDAP (輕量級目錄訪問協(xié)議)。

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

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

更多關(guān)于 JNDI 的細(xì)節(jié)，我們這里不再贅述，有興趣的可以自己做下功課，不過以下要點(diǎn)，跟大家概括下：

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

4 應(yīng)對 LOG4J JNDI 系列漏洞的思路

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

• Log4j 1.x：該系列版本不受影響，因?yàn)檫€沒有引入上述 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 外的其它版本，都可以臨時采取這種方案;(本質(zhì)是因?yàn)槲覀兤鋵?shí)沒有使用到 LOG4J 的“JNDI Lookup plugin support” 功能);
• log4j2: 不啟用 JNDI 功能: 針對 2.16.0 版本，用戶也可以配置不啟用 JNDI 功能，從而避免建立 LDAP連接的潛在可能和風(fēng)險;(2.16.0 提供了配置項(xiàng)，可以開啟或關(guān)閉 JNDI功能，所以不用刪除類加載路徑上的危險類 JndiLookup.class);

所以：

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

5 常見大數(shù)據(jù)組件如何應(yīng)對 LOG4J JNDI 系列漏洞

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

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



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

6 CDH/HDP/CDP 等大數(shù)據(jù)平臺中如何快速應(yīng)對LOG4J的 JNDI 系列漏洞

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

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

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

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