开发人员如何争相保护 Log4j 漏洞
2021年12 月 9 日，Apache 基金会发布了一个名为 Log4Shell 的严重零日漏洞的紧急更新[https://logging.apache.org/log4j/2.x/security.html]，该漏洞已在 Log4j 中发现，Log4j 是一种用于各种 Java 应用程序的开源日志框架。该漏洞标识为 CVE-2021-44228[https://www.csoonline.com/article/3644472/apache-log4j-vulnerability-actively-exploited-impacting-millions-of-java-based-apps.html]，允许攻击者在使用 Log4j 库写出日志消息的任何系统上执行任意代码。它立即被评为CVSS 量表[https://www.first.org/cvss/]上 10 的最大严重性。
正如 Cloudflare 首席技术官 John Graham-Cumming所写，“这可能是自[https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/]Heartbleed[https://www.csoonline.com/article/3223203/what-is-the-heartbleed-bug-how-does-it-work-and-how-was-it-fixed.html]和ShellShock[https://www.csoonline.com/article/2687958/shellshock-bash-vulnerability-being-exploited-in-the-wild-red-hat-says-patch-incomplete.html]以来互联网上最严重的漏洞之一 。” 甚至Minecraft 也不安全[https://www.minecraft.net/en-us/article/important-message%E2%80%94security-vulnerability-java-edition]。
第一响应者
由于开发人员和维护人员在周末立即争先恐后地修补尽可能多的 Java 应用程序。第一道防线是 Log4j 本身，它由非营利 Apache Software Foundation 的 Logging Services 团队维护。
Apache 的日志服务团队由 16 名无偿志愿者组成，他们几乎分布在世界各地的每个时区。“我们这样做是因为我们喜欢在空闲时间编写软件和解决难题，”软件工程师兼 Apache 日志服务项目管理委员会 (PMC) 成员 Gary Gregory 告诉 InfoWorld。
PMC 的主要沟通渠道是电子邮件——11 月 24 日星期三，格林威治标准时间上午 7:51，该小组收到了一封爆炸性邮件。阿里巴巴云安全团队成员陈兆军提醒他们，在他们的软件中发现了一个零日安全漏洞。
“很明显，这将是一个大问题，”格雷戈里说，周末的睡眠时间约为四个小时。
该团队很快就开始私下修复该问题，但当该漏洞在 12 月 9 日星期四被公开[https://mp.weixin.qq.com/s?__biz=MzAwNzk0NTkxNw==&mid=2247485024&idx=1&sn=bf7a39a3425e88d6b36edda7c44450c0&chksm=9b772db2ac00a4a44258d8e59ca12177f833cef8a4a44258d9e59ca12177fc]时，他们的时间线迅速加快。“请快点，”阿里巴巴的陈敦促。
Gregory 和他的维护人员同事放弃了一切，开始着手解决这个问题，他们在 12 月 10 日星期五格林威治标准时间上午 10:00发布更新[https://logging.apache.org/log4j/2.x/changes-report.html]之前，他们很快就认为 2.15 版更新“不够好” 。他们跟进2.16 版本[https://logging.apache.org/log4j/2.x/changes-report.html]于12 月 13 日格林威治标准时间晚上 10:28 发布。
“我认识这些人——他们都有家庭和必须做的事情。但他们把所有事情都放在一边，整个周末都坐下来继续努力，”前 Log4j 开发人员 Christian Grobmeier告诉彭博社[https://www.bloomberg.com/news/articles/2021-12-13/how-apache-raced-to-fix-a-potentially-disastrous-software-flaw]。
到周末的这个时候，PMC 的活跃成员已经切换到通过私人 Slack 频道进行交流，他们继续解决这个问题，并共同努力为运行旧版本 Java 的用户提供更新。他们很快发布了 2.12.2 版本来解决 Java 7 用户的问题。Java 6 的修复被证明更棘手，但在他们的积压工作中是下一个。
“总的来说，我认为尽管这种漏洞带来了可怕的后果，但事情进展得和经验丰富的开发人员预期的一样，”Gregory 说。“我们收到了通知，迅速提供了补丁并在该版本上进行了迭代。这是我在专业环境中一次又一次地看到的。”
热补丁和紧急指导
另一个在周末迅速行动的团队是 Amazon Web Services 中的 Amazon Corretto 团队。Corretto 是 Open Java Development Kit (OpenJDK) 的一个发行版，将这个团队置于 Log4Shell 问题的前线。
在首席软件工程师Volker
Simonis[https://twitter.com/volker_simonis/status/1469256987196100608?s=20]的带领下，Corretto 团队迅速为无法立即更新的任何组织构建并开源了一个热补丁。[https://aws.amazon.com/blogs/opensource/hotpatch-for-apache-log4j/]
如其GitHub 页面[https://github.com/corretto/hotpatch-for-apache-log4j2]所述：
这是一个将 Java 代理注入到正在运行的 JVM 进程中的工具。代理将尝试修补所有加载的 org.apache.logging.log4j.core.lookup.JndiLookup 实例的 lookup() 方法，以无条件地返回字符串“Patched JndiLookup::lookup()”。
该热补丁旨在解决 Log4j 中的 CVE-2021-44228 远程代码执行漏洞，而无需重新启动 Java 进程。已知动态和静态代理在 Linux 上的 JDK 8 和 JDK 11 上运行，而在 JDK 17 上只有静态代理在工作。
“非常感谢 Amazon Corretto 团队花费数天、数夜和周末来编写、强化和发布此代码，”AWS 首席信息安全官 Steve Schmidt在博客文章中写道[https://aws.amazon.com/blogs/security/open-source-hotpatch-for-apache-log4j-vulnerability/]。AWS 还发布了针对受影响产品的服务特定安全更新的详尽列表。[https://aws.amazon.com/security/security-bulletins/AWS-2021-006/]
在其他地方，由 Java 首席工程组经理 Martijn Verburg 领导的 Microsoft Java 团队成员帮助评估了该补丁，并为客户提供了更一般[https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/]的保护自己的建议，包括几个推荐的解决方法，直到可以应用完整的安全更新.
谷歌云对其 Cloud Armor 安全产品进行了更新，该产品于 12 月 11 日发布了一项紧急 Web 应用程序防火墙 (WAF) 规则
[https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability]
，以帮助检测和阻止对 CVE-2021-44228 的企图利用。
“为了帮助我们的客户解决 Log4j 漏洞，我们引入了一个新的预配置 WAF 规则，称为“cve-canary”，它可以帮助检测和阻止 CVE-2021-44228 的利用尝试，”Emil Kiner，产品经理Cloud Armor 和谷歌网络专家经理 Dave Reisfeld在周六的一篇博客文章中写道。[https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability]
你可以做什么
虽然这些内部开发人员急于为客户保护他们的软件，但许多最终用户和企业开发人员正在争先恐后地评估他们的漏洞并保护他们自己的 Java 应用程序。
首先要做的是检测 Log4j 是否存在于您的应用程序
[https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html]中。还需要注意的是，并非所有应用程序都容易受到此漏洞的攻击。由于在这些版本中增加了对 JNDI（Java 命名和目录接口）远程类加载的保护，任何使用高于 6u212、7u202、8u192 或 11.0.2 的 Java 版本的人都应该是安全的。
同样，Log4j 版本高于 2.10 的用户应通过将系统属性formatMsgNoLookups设置为 true、设置 JVM 参数-Dlog4j2.formatMsgNoLookups=true或JndiLookup从类路径中删除类来缓解此问题。
还没结束
由于 Log4j 漏洞不仅影响 Java 应用程序，而且影响使用该库的任何服务，因此 Log4Shell 攻击面可能非常大。
正如Lucian Constantin 为 CSO 所写的[https://www.csoonline.com/article/3644472/apache-log4j-vulnerability-actively-exploited-impacting-millions-of-java-based-apps.html]那样，“社区仍在努力评估攻击面，但由于依赖关系的复杂生态系统，攻击面可能很大。一些受影响的组件非常受欢迎，并被数百万企业应用程序和服务使用。”
就其本身而言，Apache 日志服务团队将“继续评估可能存在潜在安全风险的 Log4j 功能，并将进行必要的更改以删除它们。虽然我们将尽一切努力保持向后兼容性，但这可能意味着我们必须禁用他们可能正在使用的功能，”Apache Logging Services 团队的成员 Ralph Goers 告诉 InfoWorld。
即使无数开发人员在周末不知疲倦地修补 Log4j 漏洞，也会有很多人响应较慢。因此，Log4Shell 的影响可能是长期的和广泛的。
正如安全分析师托尼·罗宾逊（Tony Robinson ）在推特[https://twitter.com/da_667/status/1470267544552579074?s=20]上所说：“虽然优秀的公司通过修补来快速解决问题，但仍有很多地方不会修补，或者在一段时间内无法修补。然后你开始接触到生命终结的软件，或者可能没有打补丁。”