RHSB-2021-009 Log4Shell - 远程代码执行漏洞 - log4j (CVE-2021-44228)

执行摘要

Apache Log4j 是一个与日志功能有关的函数库，内嵌在基于 Java 的应用程序中。 

在 Apache Log4j v2 （Log4j的升级版）中发现了一个漏洞，攻击者可以注入一个恶意的字符串, 这个字符串可以以Java 命名与目录接口（JNDI）的方式来使用轻量级目录访问协议（LDAP）进行服务查询，此时攻击者就可以在这台服务器上执行恶意代码。这个漏洞允许远程攻击者在目标主机上执行恶意代码，执行代码的用户权限即为调用了 Apache Log4j v2 的 Java 应用的用户权限。 

目前上游社区已经给此问题分配了 CVE 代码 CVE-2021-44228，并且将影响级别定义为高危级别（Critical）。此问题对红帽产品的影响可以参考红帽 CVE 链接 CVE-2021-44228。

下列产品不受此缺陷的影响，在此处明确列出以方便客户。

• Red Hat Enterprise Linux

• Red Hat Advanced Cluster Management for Kubernetes 

• Red Hat Advanced Cluster Security for Kubernetes

• Red Hat Ansible Automation Platform (Engine 和 Tower)

• Red Hat Certificate System

• Red Hat Directory Server

• Red Hat Identity Management

• Red Hat CloudForms 

• Red Hat Update Infrastructure

• Red Hat Satellite

• Red Hat Ceph Storage

• Red Hat Gluster Storage

• Red Hat OpenShift Data Foundation

• Red Hat OpenStack Platform

• Red Hat Virtualization

• Red Hat Single Sign-On

• Red Hat 3scale API Management

技术概述

在 Apache Log4j 的版本 2.0.0 到 2.15.0 之前的版本中的 Java 日志函数库中发现了一个安全漏洞。一个能够控制日志信息或日志信息参数的远程攻击者，利用这个安全漏洞可以通过 JNDI LDAP 端点在服务器上执行任意代码。如需更详细的信息，请参阅 CVE-2021-44228。

缓解方案

对于 Log4j 版本 2.10 及更高版本：

• 将系统属性 log4j2.formatMsgNoLookups 或环境变量 LOG4J_FORMAT_MSG_NO_LOOKUPS 设置为 true，

对于 Log4j 版本 2.7 到版本 2.14.1：

• 可以修改所有 PatternLayout 模式，以将消息转换器指定为 %m{nolookups} 而不是仅为 %m，

对于 Log4j 版本 2.0-beta9 到版本 2.10.0：

• 从 classpath 中移除 JndiLookup 类例如： 

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

对于 OpenShift 4 和 OpenShift Logging，请参阅以下文档来应用以上的缓解方案：https://access.redhat.com/solutions/6578421

对于 OpenShift 3.11，请参阅以下文档来对受影响的 Elasticsearch 组件应用缓解方案：https://access.redhat.com/solutions/6578441

技术细节

在 Apache Log4j 的版本 2.0.0 到 2.15.0 之前的版本中的 Java 日志函数库中发现了一个安全漏洞。一个能够控制日志信息或日志信息参数的远程攻击者，利用这个安全漏洞可以通过 JNDI LDAP 端点在服务器上执行任意代码。

此问题仅影响 log4j 版本 2.0 到 2.14.1 。利用这个安全漏洞的条件：

• 带有攻击者可以发送任意数据的网络协议（如 HTTP, TCP, 等）的一个远程可访问端点，

• 端点中有一个日志声明会将攻击者控制的数据记录到日志中。

对云服务的影响

已针对所有云服务评估了 CVE-2021-44228 及相关 log4j 漏洞的影响。  发现有潜在影响的问题已被解决。对存在安全漏洞组件的使用及其造成的潜在风险因服务而异。红帽已应用了相关的缓解方案（参见上面）、补丁程序，在某些情况下移除了存在安全漏洞的组件，以及时消除存在的风险。

红帽会继续监控这些安全漏洞对红帽云服务的潜在影响，并根据需要与第三方合作，为我们的服务提供保障。  我们在以后会根据需要发布相关信息。

对受影响产品的更新

强烈建议运行这些受影响的红帽产品的客户在有勘误表时立即进行更新。并建议您在没有更新可用的情况下，通过使用缓解方案避免系统受到影响。  

[1] 公告/更新链接将在更新发布后添加。

诊断

一个安全漏洞检测脚本已被开发，用来检查您的系统当前是否存在相关的安全漏洞。您可以下载 分离的 GPG 签名 来验证脚本的真实性。红帽客户门户网站上提供了有关如何使用GPG签名进行验证说明。

Ansible Playbook

此外，我们提供了一个 Ansible playbook 可用于一次性在多个主机上运行检测脚本。playbook 需要一个额外的 vars 文件，用于控制其操作。另外，为 playbook和其变量文件提供了用于验证真实性的 GPG 签名。下载 playbook 及其关联的 var 文件后，编辑 var 文件，以使其适用于您的环境。 

您应该指定：

detector_path：检测脚本将扫描存在安全漏洞存档的路径。

detector_dir：playbook 会将检测脚本复制到远程主机上的这个目录中。

detector_run_dir：检测脚本将用于作为临时存储的路径。

要运行 playbook，您需要在命令行中指定两个额外变量：

HOSTS：要扫描的主机或组，在 Ansible 清单中定义。

vars_file：到 vars 文件的路径。

例如：

# ansible-playbook -e HOSTS=all -e vars_file=log4j-cve-2021-44228-vars.yml log4j-cve-2021-44228.yml

常问问题解答

问：请问当我们应用了这个安全补丁或者缓解方案之后，是否需要重启服务或者应用程序？如果需要重启，请告知具体应该重启什么？  

答：虽然最佳实践建议重启您的服务或应用程序，但它取决于应用程序部署策略；例如： 

• 基于 Java 的应用程序，是的，在应用安全补丁或缓解方案之后，您必须重启应用服务器。

问：在红帽 OpenShift 产品中（包含 OpenShift Logging），当有新版本更新发布之后，您只需要接受更新即可。 

1. 更多关于 OpenShift 容器平台和OpenShift 日志组件更新过程的介绍，请阅读以下文档：

• 理解 OpenShift Update Service

• 更新 OpenShift 日志

问：ARO/OSD/ROSA 等服务是否存在安全漏洞？ 

答：不存在，根据以下所述的信息： 

Apache Log4j2 Remote Code Execution (RCE) 安全漏洞

问：在应用上述 Log4j v2 更新后，我是否还需要等待 CVE-2021-45046, CVE-2021-45105 和 CVE-2021-44832 中发布的安全勘误？

答：不需要。您不必等待 CVE-2021-45046, CVE-2021-45105 和 CVE-2021-44832 中发布的新安全勘误。这三个 CVE 的严重性都为 MODERATE（中度）。除非在产品的 Log4J 配置中使用了非默认的、带有上下文查找（例如 $${ctx:loginId}）的 Pattern Layout（这没有被默认配置，在开箱即用的红帽产品中都未使用），否则您不会受到这些问题的影响。

问：有些红帽产品提供了 Log4j v1。此安全公告中提到的更新是否也可以修复 Log4j v1 中的漏洞？

答：Log4j 版本 1.x 不受 CVE-2021-44228 (Log4Shell) 的影响。对于 Log4j v1.x，根据受影响的库或组件会有独立的已知问题（如下所述），在与默认配置一起使用时，大多数都不受影响。

• CVE-2021-4104 (Log4j v1.x JMSAppender) 的严重性级别为 Moderate（中度）。当攻击者对 Log4j 配置具有写入访问权限或配置为使用启用特定选项的 JMSAppender（而不是默认配置）时，Log4j v1.2 可能会在对不信数据进行反序列化处理过程中受到安全漏洞的影响。 

• CVE-2022-23302 (Log4j v1.x JMSSink) 的严重性级别为 Moderate（中度）。Log4j 1.x 在对不信任的数据进行反序列化处理过程中存在安全漏洞。只有在应用程序被特别配置为使用 JMSSink（这不是默认设置），或攻击者有对 Log4j 配置的写权限来将 JMSSink 添加到攻击者的 JNDI LDAP 端点时，应用程序才会受到这个安全漏洞的影响。

• CVE-2022-23305 (Log4j v1.x JDBCAppender) 的严重性级别为 Important（重要）。Log4j v1.x 中的 JDBCAppender 存在受到不受信任的数据中的 SQL 注入的安全漏洞。请注意，只有在特别配置为使用 JDBCAppender 而不是默认值时，这个问题才会对 Log4j v1.x 有影响。

• CVE-2022-23307 (Log4j v1.x Chainsaw) 的严重性级别为 Important（重要）。在 log4j v1.x chainaw 组件中发现了一个安全漏洞，特定日志条目的内容会被反序列化，可能允许代码执行。Chainsaw 是用来查看 log4j 中日志条目的独立图形用户界面。使用其他方式访问日志条目，可以避免此漏洞。

有关更多详细信息，请参阅相关的 CVE 页面。 

参考信息

• Log4j 中的远程代码注入 - Github 

• Apache Log4j 安全漏洞

• Log4Shell：log4j2（一个流行的 Java 日志软件包）中发现 RCE 0-day 安全漏洞