小伙伴们好，我是明哥!
最近 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 的关键构成部分，是20世纪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