Cdh/Hdp/Cdp等大数据平台中如何快速应对Log4j的Jndi系列漏洞

大家好，我是明哥!

近期 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