SPARK 应用如何快速应对 LOG4J 的系列安全漏洞

大家好，我是明哥！

1. CDH/HDP/CDP 等大数据平台中如何快速应对 LOG4J2 的 JNDI 系列漏洞

在前段时间发表的博文 “CDH/HDP/CDP 等大数据平台中如何快速应对 LOG4J 的 JNDI 系列漏洞” 中，我们描述了 CDH/HDP/CDP 等大数据平台中如何快速应对 LOG4J 的 JNDI 系列漏洞，其核心关键是：

正式的最终修复方案：是等待大数据平台供应商如 Cloudera 提供的正式的修复包，但由于大数据平台供应商需要在大数据平台底层的多个开源组件都有了正式修复包后，才能整合测试并发包，所以一般进度相对落后；
快速的临时修复方案：由于大数据平台底层的众多大数据组件，在使用 LOG4J 时，只使用了 LOG4J 的基本功能，并没有使用到 LOG4J 的 “JNDI Lookup plugin support” 功能，所以可以粗暴删除大数据平台底层众多 JAR 包中的危险类 JndiLookup.class；
辅助工具包：Cloudera 在 GitHub 上提供了系列脚本，来辅助删除 CDH/HDP/CDP 等大数据平台上的危险类 JndiLookup.class，大家可以去 GITHUB 自行下载，GITHUB 下载链接如下：https://github.com/cloudera/cloudera-scripts-for-log4j.git

在前段时间发表的博文 “CDH/HDP/CDP 等大数据平台中如何快速应对 LOG4J 的 JNDI 系列漏洞” 中，我们描述了大数据计算组件 FLINK，如何快速应对 LOG4J 的 JNDI 系列漏洞，其核心关键是：

Flink1.11 及以后版本，使用的是 LOG4J2.X 系列，会受到上述 JNDI 系列漏洞影响；Flink 1.11 以前的版本，由于使用的是 LOG4J1.X 系列，不会受到上述 JNDI 系列漏洞影响；
flink 组件正式的修复方案是升级 flink: 得益于 flink 社区快速即使的响应和修复，目前 flink 社区已经发布了针对 1.11/1.12/1.13/1.14 系列的修复版本，大家可以根据自己的情况，升级到同系列下最新版本即可修复该问题；
如果线上应用因为各种原因，不能或不方面升级 Flink，大家仍可以采用临时修复方案，即删除 JAR 中 log4j-core 里的 JndiLooup.class，以达到禁用 JNDI 的效果；

image

在前段时间发表的博文 “CDH/HDP/CDP 等大数据平台中如何快速应对 LOG4J 的 JNDI 系列漏洞” 中，我们指出了：

spark 的最新版本是 3.2.0，目前其依赖的还是 log4j1.2.17，即 log4j1.x 系列，所以不受上述 LOG4J JNDI 系列漏洞影响（截至到 01/19/2022）。

但这是否代表，SPARK 使用的 LO4GJ 就没有安全漏洞呢？答案是否定的。

从以下 maven 的官方截图可以看出，SPARK3.2 底层有多个安全漏洞，其中有两个是跟 LOG4J 相关的，即：CVE-2021-4104 和 CVE-2019-17571；(spark2.x 和 spark3.x 目前使用的都是 log4j1.x);
点开连接，可以看到这两个 CVE 的级别，分别达到了 HIGH 和 Critical,所以同样是高风险，是需要应对的；

image

仔细分析下这两个高危漏洞 CVE-2021-4104 和 CVE-2019-17571:

CVE-2019-17571：Log4j 1.2 中包含一个 SocketServer 类，该类易受不可信数据反序列化的影响，当侦听不可信网络流量以获取日志数据时，该类可被利用与反序列化小工具结合使用以远程执行任意代码，这会影响从 1.2 到 1.2.17 的 Log4j 版本;
CVE-2021-4104： Log4j 1.2 中包含一个 JMSAppender 类，该类易受不可信数据反序列化的影响，当攻击者对 LOG4J 配置文件有写权限时，可以通过更改配置文件指定使用 JMSAppender，达到类似 CVE-2021-44228 的远程执行任意代码的效果。（底层机制是通过指定 TopicBindingName 和 TopicConnectionFactoryBindingName，使得 JMSAppender 发起 JNDI 请求）；
当未使用 Log4j 的 SocketServer 类和 JMSAppender 类的功能时，不受此漏洞影响，亦即默认情况下只使用 Log4j local logging 时，是不会触发风险的的；
两外，Apache Log4j 1.2 系列在 2015 年 8 月份后，官方不再维护，各应用需要升级使用 LOG4J 2.X;

那么 SPARK 如何应对 LOG4J 的上述系列安全漏洞呢？

不使用 Log4j 的 SocketServer 类创建 Socket 服务，同时也不主动使用 Log4j 的 JMSAppender，同时做好 LOG4J 的配置文件的权限管理，防止被篡改使用 JMSAppender；
为彻底杜绝问题，也可以把问题类从 jar 包中删除掉：包含 org/apache/log4j/net/JMSAppender.class 和 org/apache/log4j/net/SocketServer.class；
正式的永久解决方案：等待 SPARK 官方的升级修复包，Spark 官方已经宣布将在 Spark3.3.0 版本升级使用 log4j2 的 2.x 系列，但该版本目前还没有正式发布；