大家好，我是明哥！最近LOG4J频频爆出围绕JNDI安全漏洞的暴雷，着实让大家忙了一阵子。本篇我们就来看看如何在CDH/HDP/CDP等大数据平台快速处理LOG4J的JNDI系列漏洞。1LOG4J概述2LOG4JJNDI系列漏洞概述3深入理解LOG4J和JNDI4LOG4JJNDI系列漏洞处理思路5常见大数据组件如何处理LOG4JJNDI系列漏洞6如何快速处理LOG4J漏洞CDH/HDP/CDP等大数据平台JNDI系列漏洞1LOG4J概述ApacheLog4j是一个基于Java的开源日志框架，ApacheLog4j2指的是另一个基于Log4j的日志框架logback，并做了很多改进，增加了许多丰富的功能。在实现上，log4j2实现了api分离，包括log4j-core和log4j-api，前者是日志框架的具体实现（Logback是日志框架的另一种具体实现），后者是日志门面/log抽象日志外观（SimpleLoggingFacadeforJava(slf4j)是另一个日志外观/日志抽象）。在性能方面，由于Log4j2使用了Asynchronousloggers，（当应用程序代码调用Logger.log时，实际上是将I/O操作的执行交给另一个IO线程，并立即返回给应用程序线程），在多线程环境在这种情况下，LOG4J1.X和logback的吞吐量可以提高18倍，延迟更低。在架构上，log4j2采用插件机制，用户可以根据自己的情况配置自己的Appender/Layout/PatternConverter，无需额外编写代码，log4j2会自动识别配置文件并使用配置的插件在里面。正式由于以上优势，log4j成为了JAVA生态中使用最广泛的日志框架。2LOG4JJNDI系列漏洞概述最近的JNDI系列漏洞，包括以下三个：CVE-2021-44228：该漏洞由阿里云于12月9日发现并上报。攻击者可基于该漏洞构造恶意请求，触发远程代码执行漏洞；Log4j团队发现问题后第一时间发布了2.15.0版本，并给出了临时解决方案；（危险等级：严重）CVE-2021-45046：12月14日由推特发现并报告该漏洞，说明2.15.0中对CVE-2021-44228的修复和给出的临时解决方案尚未完成，将在某些配置条件下仍会被利用来引起DOS攻击；Log4j团队发现这个问题后，发布了2.16.0版本，同时给出了新的临时解决方案；（危险等级：严重）CVE-2021-45105：12月18日，该漏洞被发现并确认，该漏洞进一步表明2.16.0版本及CVE-2021-45046的临时修复仍有被攻击的风险在某些配置条件下通过DOS；随后，Log4j团队立即发布了2.17.0版本，并给出了新的临时修复；（危险级别：中等）以上JNDI系列漏洞，LOG4J2官方团队已修复，综上，针对CVE-2021-44228和CVE的临界级别-2021-45046，解决方案如下：Log4j1.x不受该漏洞影响。log4j2：升级到Log4j2.3.1（对于Java6）、2.12.3（对于Java7）或2.17.0（对于Java8及更高版本）。log4j2：在除2.16.0以外的任何版本中，您可以从类路径中删除JndiLookup类：zip-q-dlog4j-core-*.jarorg/apache/logging/log4j/core/lookup/JndiLookup.classlog4j2：üLog4j2.16.0版本建议服务器不要启用JNDI，因为它仍然允许LDAP连接。3深入理解LOG4J和JNDI上面的JNDI系列漏洞可以追溯到Log4j早年引入的一个Feature：LOG4J2-313：JNDILookuppluginsupport：2013年，Log4j在2.0-beta9版本中增加了“JNDILookupplugin”功能。JNDI其实是Java在1990年以后推出的一种目录服务，它是J2EE的重要组成部分，允许Java程序以Java对象的形式通过目录查找数据。JNDI提供了各种SPI来支持不同的目录服务，例如CORBACOS（通用对象服务）、JavaRMI（远程方法接口）注册表和LDAP（轻量级目录访问协议）。根据JNDI官方帮助文档描述“如果你的LDAP服务器位于另一台机器上或者正在使用另一个端口，那么你需要编辑LDAPURL”，LDAP服务器可以运行在不同的机器上，或者互联网上的任何地方跑步。这种灵活性意味着如果攻击者控制了LDAPURL，他们可以让Java程序从他们控制的服务器加载对象。在存在该漏洞的Log4j版本中，攻击者可以通过传入类似“${jndi:ldap://example.com/a}”的字符串来控制Log4j访问的LDAPURL。在这种情况下，Log4j将连接到example.com上的LDAP服务器并检索对象。关于JNDI的更多细节，这里就不赘述了，有兴趣的可以自己做功课，不过总结一下以下几点：JNDI是J2EE的重要组成部分，是在1990年代引入的。JBoss、WebLogic、WebSphere等应用容器拥有大量的应用；在单体架构没落，微服务架构越来越流行的今天，大家普遍采用Springboot/springcloud技术栈，JNDI已经用的不多了；（尤其是互联网公司和中小企业，很多同学可能对JNDI不是很了解）；LOG4J通过LOG4J2-313引入“JNDILookuppluginsupport”特性，更迎合采用单一架构，使用JBoss、WebLogic、WebSphere等应用容器的大客户和大企业；在微服务架构中使用LOG4J时，大部分用户无法使用其“JNDILookuppluginsupport”功能；在使用LOG4J的大数据组件中，不能使用其“JNDILookuppluginsupport”功能；4处理LOG4JJNDI系列漏洞的思路从根本上说，处理LOG4JJNDI系列漏洞的思路，在其官方文档中有描述，如下：Log4j1.x：该系列版本不受影响，因为上面提到的LOG4J2-313还没有引入：JNDILookuppluginsupport；log4j2：官方解决方案是升级版：升级到Log4j2.3。1(forJava6),2.12.3(forJava7),or2.17respective.0(forJava8andlater);log4j2:作为临时解决方案，可以删除类加载路径上的危险类JndiLookup.class:2.16.0以外的其他版本可以暂时采用这种方案；(其实质是因为我们没有真正使用LOG4J的“JNDILookuppluginsupport”功能);log4j2:donotenableJNDIfunction:forversion2.16.0,使用用户也可以配置不开启JNDI功能，避免建立LDAP连接的潜在风险；（2.16.0提供了配置项，可以启用或禁用JNDI功能，所以不需要删除类加载路径上的危险类JndiLookup.class）;所以：如果你的应用代码直接依赖LOG4J，你可以灵活采用上述适合自己的方案。最推荐的当然是升级LOG4J版本；依赖，可以使用一个临时的解决办法，就是删除危险的类JndiLookup。5常见大数据组件如何处理LOG4JJNDI系列漏洞漏洞；flink：所有版本的flink都使用log4j的版本如下。可以看出，flink1.11及之后版本受上述漏洞影响；因此，对于flink组件，官方的修复方案是升级flink。目前flink社区已经发布了1.11/1.12/1.13/1.14系列的Repair版本，大家可以根据自己的情况升级到同系列的最新版本来解决这个问题：感谢快速及时的响应和flink社区的修复，不需要使用各种临时修复方案（主要思路是删除log4j-core中的JndiLooup.class，达到禁用JNDI的效果）6如何快速应对LOG4JJNDI系列CDH/HDP/CDP等大数据平台漏洞由于CDH/HDP/CDP等大数据平台，背后有很多大数据组件，并不是每个组件背后的社区都能快速响应，修复上述问题LOG4JJNDI系列漏洞并提供正式修复版本，所以在CDH/HDP/CDP等大数据平台，快速响应LOG4JJNDI系列漏洞，采用的思路是利用上面的临时解决方案，即删除危险类类加载路径上的ssJndiLookup.class（本质上是因为这些大数据组件底层没有使用LOG4J的“JNDILookuppluginsupport”功能）。同时，为了进一步简化临时解决方案的实施难度，Cloudera在GitHub上提供了一系列脚本，协助删除CDH/HDP/CDP等大数据平台上的危险类JndiLookup.class。其他大数据平台，如TDH，也有类似的想法。大家可以参考上面的脚本，有针对性的进行修改。以上脚本大家可以自行去GITHUB下载。GITHUB下载链接如下：https://github.com/cloudera/cloudera-scripts-for-log4j.git
