Apache Log4j

Log4j是Apache的一个开源项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。

漏洞及修复情况

CVE-2021-44228

  • 漏洞简介： 攻击者可以远程执行代码。（RCE远程代码攻击， Remote Code Execution）
  • 漏洞细节： 输入包含恶意服务器的JNDI查找时， Log4j 解析JNDI 查找， 连接到服务器，并从服务器下载序列化的Java代码，在反序列化的时候执行这些恶意代码。
  • 详情链接：NVD - CVE-2021-44228 (nist.gov)
  • 修复建议：Apache 软件基金会 (ASF) 迅速发布了针对CVE-2021-44228的补丁程序（Log4J 2.15.0 版本 ），但此修复部分解决了某些非默认配置中的缺陷。

CVE-2021-45046

  • 漏洞介绍：发现在某些非默认配置中，Apache Log4j 2.15.0中解决CVE-2021-44228的修复程序不完整。当日志记录配置使用非默认模式布局和上下文查找（例如，$${ctx：loginId}）或线程上下文映射模式（%X、%mdc 或 %MDC）时，这可能允许控制线程上下文映射 （MDC） 输入数据的攻击者使用 JNDI 查找模式制作恶意输入数据，从而导致某些环境中的信息泄漏和远程代码执行以及所有环境中的本地代码执行。
  • 漏洞动态：关于CVE-2021-45046这个洞，刚披露的时候只是说在某些特定条件下可导致拒绝服务，CVSS评分也只有3.7，后来经过安全人员的研究，在某些特定条件下，还可以RCE。官方也将该漏洞的CVSS评分改为了9.0
  • 详情链接：NVD - CVE-2021-45046 (nist.gov)
  • 修复情况：Log4j 2.16.0 版本的发布解决了这两个问题，该版本通过删除对消息查找模式的支持和默认禁用 JNDI 功能来修复 第二个漏洞CVE-2021-45046

CVE-2021-45105

  • 漏洞介绍：Apache Log4j2 版本 2.0-alpha1 到 2.16.0（不包括 2.12.3）无法防止来自自引用查找的不受控制的递归。这允许控制线程上下文映射数据的攻击者在解释精心编制的字符串时导致拒绝服务。
  • 详情链接：NVD - CVE-2021-45105 (nist.gov)
  • 修复情况：Apache Log4j 2.17.0 版本已正式 发布 ，解决了被发现的 CVE-2021-45105。从 2.17.0 版本开始（针对 Java 8），只有配置中的查找字符串才会被递归扩展；在任何其他用法中，仅解析顶层查找，不解析任何嵌套查找。

漏洞规模及影响

据悉，此前披露的 Log4j 漏洞共涉及 35000 多个 Java 包，占 Maven 中央存储库的 8% 以上（存储库是最重要的 Java 包存储库，它为软件行业带来了广泛的成果）。专家指出，对于整个生态系统而言，8% 是一个较大的数值了，因为 Maven Central advisories 结果的平均数值为 2%，中位数小于 0.1%。当然，上面提到的数字并未包含所有 Java 包（如直接分发的二进制文件）。

对此，谷歌 Open Source Insights Team 团队的专家们指出了阻碍修复过程的两个重要问题：

一、许多软件包间接依赖于 log4j。直接依赖项受影响软件约 7000 个，在此情况下，任何版本都依赖于 CVEs 中描述的受影响版本的 Log4j core 或 Log4j API（间接依赖或传递依赖是指自我依赖的依赖关系）。

Apache Log4j - 图1

所有依赖项的工作人员，在修复是否使用依赖项链查看时产生了重大障碍：漏洞陷得越深，修复它的步骤就越多。根据该团队的消费者依赖关系图，柱状图结果显示了大量的数据。超 80% 的软件包中，漏洞的深度超过一级。在大多数情况下，受影响的级别下降了 5 级（有些甚至下降了 9 级）。修复的过程需要先到最深的依赖项，然后再到所有分支。

二、依赖解析算法和需求规范约定中的生态系统级选择。这种做法不同于 npm，npm 通常为依赖需求指定开放范围（开放范围提供了选择满足依赖性要求的最新发布版本的机会）。随后它又推出了新的修复方案，修补程序可用后，用户将在下一次生成时收到修补版本，可以更快地生成依赖项。

谷歌 Open Source Insights Team 团队表示，在 Java 生态系统中，通常的做法是指定“软”版本要求——若在依赖关系图中前面没有出现同一包的其他版本，则解析算法使用的确切版本。传播修复通常需要维护人员采取明确的行动，将依赖项需求更新为修补版本。

有了以上这些，谷歌开源洞察团队（Open Source Insights Team）便建议开源社区启用自动依赖项更新并添加安全缓解措施。他们还提供了 500 个受影响包的列表，其中一些包具有极高的可传递性。专家们认为，对这些包进行优先排序将有助于修复工作，并随后清除社区中的更多障碍，并对那些升级了 Log4j 版本的开源维护人员和消费者表达了感谢。

Apache Log4j - 图2

对于究竟需要多长时间才能完全修复所有问题，谷歌 Open Source Insights Team 团队也给出了自己的判断：很难知道。如果所有影响 Maven 软件包的关键建议都是公开披露的，那么这个过程可能需要一段时间。谷歌团队表示，受漏洞影响的软件包中只有不到一半（48%）得到修复。但在 Log4j 方面，大约 13% 的问题已得到解决，前景应该是光明的。