【51CTO.com快译】12月9日，Apache 基金会针对一个名为 Log4Shell 的关键零日漏洞发布了紧急更新，这个在Log4j（一个用于各种Java应用的开源日志框架）中发现的漏洞被认定为CVE-2021-44228，允许攻击者在任何使用Log4j库写出日志信息的系统上执行任意代码。它立即被评为CVSS等级中的最高严重程度10级。
正如 Cloudflare 首席技术官John Graham-Cumming所说："这可能是自 Heartbleed 和 ShellShock 以来互联网上最严重的漏洞之一。"
加固第一道防线
在漏洞被公布之后，开发人员和维护人员立即着手给他们的 Java 应用程序打上尽可能多的补丁。由16名无报酬志愿者组成的 Apache 软件基金会日志服务团队也第一时间加固 Log4j 本身。
北京时间11月24日，Apache日志服务项目管理委员会（PMC）收到了一封爆炸性的邮件。阿里云安全团队报告了Log4j2 软件中存在一个零日安全漏洞。
软件工程师、PMC 成员 Gary Gregory 表示：“这将是一个重大的问题。”
该团队立刻开始修补这个问题，但这个漏洞在12月9日被公之于众后，他们的时间安排迅速加快了。
Gary和其他维护者放下手上的工作，加班加点来修复这个漏洞问题。在发布 2.15 版更新之前，他们很快决定这个更新“不够好”，随后，他们在格林尼治标准时间12月13日晚上10点28分发布了2.16版本。
"我知道他们都有家庭和他们必须做的事情。但他们把一切都放在一边，整个周末都在修复这个漏洞。"前 Log4j 开发者 Christian Grobmeier 告诉彭博社。
到周末的这个时候，PMC的活跃成员已经转向通过私人Slack频道进行沟通，在那里他们继续解决这个问题，并共同努力为操作旧版本 Java 的用户提供更新。他们很快就发布了 2.12.2 版本来解决 Java7 用户的问题。Java6 的修复被证明更棘手，但这是他们的下一个待办事项。
“总的来说，我认为尽管这种漏洞会带来可怕的后果，但事情进展得如经验丰富的开发人员所预料的那样，” Gary 说。“我们收到通知，迅速提供了补丁并在该版本上进行迭代。
构建热补丁和紧急指导
另一个在周末迅速行动的小组是亚马逊 Corretto 团队。Corretto 是 Open Java Development Kit (OpenJDK) 的一个发行版，这使 Corretto 团队处于Log4Shell问题的第一线。
在首席软件工程师Volker Simonis的带领下，Corretto团队迅速建立并开源了一个热补丁，供任何无法立即更新的组织使用。
正如GitHub页面上所描述的那样：
- 这是一个将 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上只有静态代理在工作。
"非常感谢亚马逊Corretto团队花了几天、几夜和周末的时间来编写、加固和运行这段代码，"AWS CISO Steve Schmidt在一篇博文中写道。AWS还发布了一份针对受影响产品的特定服务安全更新的详尽清单。
在其他地方，由 Java 首席工程组经理 Martijn Verburg 领导的 Microsoft Java 团队成员帮助评估了该补丁，并为客户发布了更一般的保护自己的建议，包括几个推荐的解决方法，直到可以应用完整的安全更新.
谷歌云以更新其Cloud Armor安全产品作为回应，该产品于 12 月 11 日发布了一项紧急 Web 应用程序防火墙 (WAF) 规则，以帮助检测和阻止 CVE-2021-44228 的企图利用。
“为了帮助我们的客户解决 Log4j 漏洞，我们引入了一个名为“cve-canary”的新预配置 WAF 规则，它可以帮助检测和阻止 CVE-2021-44228 的漏洞利用尝试，”Cloud Armor的产品经理Emil Kiner和谷歌的网络专家经理 Dave Reisfeld 在一篇博文中写道。
你可以做什么？
当这些内部开发人员匆匆忙忙为客户保护他们的软件时，许多最终用户和企业开发人员正争先恐后地评估他们的漏洞并保护他们自己的Java应用程序。
首先要做的是检测Log4j是否存在于你的应用程序中。同样重要的是要注意，不是所有的应用程序都会受到这个漏洞的攻击。任何使用高于6u212、7u202、8u192或11.0.2的Java版本的人都应该是安全的，因为这些版本中增加了对JNDI（Java命名和目录接口）远程类加载的保护。
同样，高于2.10版本的 Log4j 用户应该通过设置系统属性formatMsgNoLookups为true，设置JVM 参数-Dlog4j2.formatMsgNoLookups=true，或从classpath中删除JndiLookup类来缓解这一问题。
由于Log4j漏洞不仅影响Java应用程序，而且还影响使用该库的任何服务，因此Log4Shell的攻击面可能非常大。
正如Lucian Constantin为CSO写的那样："社区仍在努力评估攻击面，但由于依赖关系的复杂生态系统，它可能是巨大的。一些受影响的组件是非常流行的，被数以百万计的企业应用和服务所使用"。
就其本身而言，Apache Logging Services团队将 "继续评估可能存在潜在安全风险的Log4j功能，并将进行必要的修改以删除这些功能。Apache Logging Services团队的成员Ralph Goers告诉InfoWorld，"虽然我们将尽一切努力保持向后兼容，但这可能意味着我们必须禁用他们可能正在使用的功能。
即使无数的开发者在周末不知疲倦地修补Log4j的漏洞，也会有很多人反应较慢。因此，Log4Shell的影响可能是长期和广泛的。
正如安全分析师Tony Robinson在推特上所说。"虽然那些好的公司通过打补丁迅速解决了问题，但还是会有很多地方不会打补丁，或者在一段时间内无法打补丁。"
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
