Log4j 持续爆雷，啥时候是个头？

| 2021-12-22

图1: undefinedLog4j 持续爆雷，啥时候是个头？

据媒体报道，近期工信部网络安全管理局通报称，阿里云计算有限公司（以下称：阿里云）在 11 月 24 日发现了 Log4j2 安全漏洞隐患后率先向 Apache 基金会披露了该漏洞，未及时向中国工信部通报相关信息，未有效支撑工信部开展网络安全威胁和漏洞管理。经研究，工信部网络安全管理局决定暂停阿里云作为上述合作单位 6 个月。暂停期满后，根据阿里云整改情况，研究恢复其上述合作单位。

根据工信部官网消息，工业和信息化部网络安全威胁和漏洞信息共享平台 12 月 9 日收到有关网络安全专业机构报告后，立即组织有关网络安全专业机构开展漏洞风险分析。

工信部官网截图

漏洞波及范围极广

由于漏洞利用门槛不高、Log4j 应用范围广，所以这次 Log4j 漏洞事件引发的安全影响十分深远。

根据谷歌安全团队的统计，截至 2021 年 12 月 16 日，来自 Maven Central 的 35,863 个可用 Java 组件依赖于 Log4j。这意味着 Maven Central 上超过 8% 的软件包里至少有一个版本会受此漏洞影响。漏洞修复前，攻击者可以通过利用日志库 Log4j 公开的不安全 JNDI 查找功能来执行远程代码执行，而这项功能在该库的许多版本中默认启用。

对于生态系统来说，8% 的数字是巨大的。该漏洞对 Maven Central 生态系统的平均影响为 2%，中位数低于 0.1%。

来源：谷歌安全

其中，受影响组件中有 7,000 个为直接依赖项，这意味着其任何版本都依赖于受影响的 Log4j-core 或 Log4j-api 版本。而大多数受影响的组件来自间接依赖项（即自己依赖项的依赖项），这意味着 Log4j 没有明确被定义为组件的依赖项，而是作为传递依赖项去影响这些组件。

来源：谷歌安全

漏洞在依赖链中越深，修复步骤就越多。因此，对于整个软件生态来说，Log4j 漏洞事件影响巨大。

根据Cloudflare 研究人员的观测，每秒有超过 1000 次利用 Log4j 漏洞的尝试。有不法分子利用远程代码执行漏洞窃取云基础设施，部署加密货币矿工和勒索软件。

近日，比利时国防部已确认在其网络上发生了涉及 Log4j 漏洞的网络攻击。比利时国防部发言人Olivier Séverin表示，不法分子在上周利用 Log4j 漏洞攻击了比利时国防部。该部在周四发现了其上网的计算机网络遭到攻击，之后便迅速采取措施隔离了受影响的部分。“一些活动已经瘫痪了好几天”。比利时国防部成为这次事件中首次公开披露的受害者。

不断爆出的漏洞

尽管距离第一个漏洞曝出已经过去十多天，但修复的工作仍未停止。

12 月 9 日，Apache Log4j2 被曝出一个高危漏洞，攻击者通过 jndi 注入攻击的形式可以轻松远程执行任何代码。该漏洞被命名为 Log4Shell，编号 CVE-2021-44228。随后官方紧急推出了 2.15.0 和 2.15.0-rc1 新版本修复，依然未能完全解决问题。

12 月 12 日，安全公司Blumira 发现 Log4j 漏洞出现了另外一种攻击载体，它通过使用底层的 JavaScript WebSocket 连接，通过驱动式的破坏，在本地服务器上触发远程代码执行（RCE）漏洞进行攻击。换句话说，攻击者可以利用漏洞攻击那些并不暴露于任何网络内部系统中的以 localhost 运行的服务。

Blumira 公司的研究人员指出，这一发现推翻了 Log4Shell 攻击仅限于暴露的有漏洞的网络服务器的说法。

“最新攻击载体的出现意味着，任何使用有漏洞 Log4j 版本的用户都可以通过他们机器上的监听服务器路径或浏览本地网络，触发该漏洞。”这意味着更多新的恶意攻击方式的存在。

12 月 14 日，Apache Log4j 2 团队发布了 Log4j 2.16.0 版本，主要修复第二个漏洞 CVE-2021-45046。2.16.0 版本主要做了以下修改：

Log4J2-3208：默认禁用 JNDI。需要手动设置来允许 JNDI 运行。
Log4J2-3211：完全删除对消息查找的支持。
Apache Log4j 2.16.0 至少需要 Java 8 才能构建和运行。Log4j 2.12.1 是最后一个支持 Java 7 的版本。Java 7 不是 Log4j 团队的长期支持版本。

不过，让人没想到的是，Log4j 2.16.0 又“爆雷”了。

12 月 15 日，安全公司 Praetorian的研究人员警告说，为修复最初的 Log4Shell 而发布的 Log4j 2.15.0 版存在第三个安全漏洞。在某些情况下，攻击者可以利用第三个漏洞来窃取敏感数据。不过 Praetorian 表示，为了避免出现更大的问题，不会公开分享技术细节，但已经将相关细节告知了 Apache 基金会。

12 月 17 日，Apache 软件基金会紧急发布了修补后的 2.17.0 新版本，并随后发布了一个新补丁。官方承认 2.16.0 版本无法在查找评估中妥善防止无限递归，因而易受 CVE-2021-45105 攻击的影响。

具体来说，Apache Log4j2 的 2.0-alpha1 到 2.16.0 版本，均未能防止自引用查找的不受控递归。当日志配置使用了带有上下文查找的非默认模式布局时（例如 ${ctx:LoginId}），控制线程上下文映射（MDC）数据输入的攻击者，便可制作一份包含递归查找的恶意输入数据，从而导致进程因堆栈溢出报错而被终止。

CVSS 对这次的拒绝服务（DoS）攻击评分达到了 7.5/10 。据悉，这次的漏洞由 Akamai TechnoLogies 的 Hideki Okamoto 和另一位匿名漏洞研究人员发现的。

CVE-2021-45105 影响的版本包括 2.0-alpha1 至 2.16.0（1.x 用户继续忽略）。不过受影响的只有 Log4j-core，仅使用 Log4j-api 的程序不需要担心，用户可以通过升级 Log4j-core 来修复该漏洞。

Log4j 2.17.0 下载地址如下：

https://Logging.apache.org/Log4j/2.x/download.html

此外，360CERT 发布了 Log4j2 恶意荷载批量检测调查工具，腾讯容器安全发布了开源 Log4j2 漏洞缓解工具。华为、微软等多家企业还在进行排查测试。

Log4j 展现出的开源“致命伤”

虽然已经过去了十多天，但 Log4j 中暴露出的安全漏洞仍在肆虐，同时也唤起了大家对于开源软件开发、付费与维护方式的深切思考。

有人抨击项目维护者未能及时发现问题。面对这样的指责，开发者 Volkan Yazici 立即对这种践踏无偿志愿劳动的行径展开反击，表示这群“嘴炮”自己压根没提供过任何财务支持或者代码贡献。

Log4j2 维护者只有几个人，他们无偿、自愿地工作，没有人发工资，也没人提交代码修复问题，出了问题还要被一堆人留言痛骂。——Volkan Yazici

多年以来，开源项目维护者心中最大的痛，就是无数企业只是免费使用成果、但却从不对开源社区作出任何回馈。这一危机也被称为开源可持续性问题，社区的健康生存与企业客户的成本最小化和利润最大化意图之间，存在天然的冲突。

不少开源项目希望建立起自己的盈利能力，并避免优秀的志愿者被其他更为成熟的企业巨头挖走。这种对抗性关系也让开源社区普遍产生了“科技巨头粗暴掠夺开源生态”的观点，导致双方几乎势同水火。

开源可持续性问题之争

上周，谷歌密码学家兼 Go 编程语言安全负责人 Filippo Valsorda 在权衡当前状况之后，呼吁开源维护者与其企业客户开展更为专业的交流，通过付费方式增强开源项目的可持续性。他在个人博文中写道，“维护者需要拿出一套明确的解决方案，以供大型科技企业的决策与财务部门审查。毕竟没有哪家企业会用微信转账的方式支付律师费。”

Dan Lorenc 在供职近九年之后，于今年 10 月离开了谷歌并创立安全公司 Chainguard。他表示从与开源项目的交互来讲，谷歌面临的最大问题不是有没有钱、而是如何花钱。他在Twitter上解释道，“企业有这笔预算而且很愿意花钱，但花钱也是门学问。我们往往很难联系上那些真正需要帮助的项目、或者是愿意用自己的精力投入换取资金报酬的维护者。”

至于直接跳过参与开源项目的个人、直接向开源产品付费的思路，也同样面临着不少现实阻碍。个人开发者和大型科技企业都很少有向作为产品、项目及服务核心的开源软件付费的热情。

“我之前跟很多人聊过这个问题，他们的回应让我很难相信高度分散的志愿贡献者真能从项目中拿到体面的收益。”开发人员 Christine Dodrill 在一篇博文中提到，开源文化好像从始至终一直强调只付出、不求回报的价值观。

然而，有讨论者认为资金并不是问题。

Tailscale 公司 CTO David Crawshaw在博文中提到，虽然 Yazici 关于 Log4j 缺钱、缺人的文章被广为关注，特别是其中“大公司正利用这些免费基础设施赚得盆满钵满”的观点确实有理，但单是有钱“并不能有效防止这类 bug 的出现。”

Curl 缔造者、WolfSSL 开发人员 Daniel Stenberg 也对此表示赞同。他认为，Log4j 漏洞绝不是缺钱导致的。这个问题源自天真幼稚的用户在使用组件之前缺乏一切必要的尽职调查、代码审查或者测试工作。“大家还记得苹果的 GoToFail Bug 吧？事实证明钱解决不了因愚蠢产生的 bug。”

开发者 Gabriella Gonzalez 也详细阐述了这个问题。他认为 Log4j 漏洞凸显出开源项目过度迎合大型企业需求的问题。此次 bug 的根源正是为了实现企业的向下兼容需求而强行“续命”的功能 LDAP/JNDI URL。

“Log4j 项目的维护者们当然知道这项鲜为人知的功能可能存在问题（只是低估了最终影响），但他们为了维持向下兼容性而没有删除该项功能。”Gonzalez 在一篇博文中写道。他认为，Log4j 问题只是暴露出了更深层次的危机预兆：上市企业正在疯狂剥削并滥用开源成果。

大型企业在开源领域外的表现也让很多开发者失去对其的信心：

Uber 和 Lyft 都在通过游说引导加州民众对抗一项法律（但已被法官认定为违宪），拒绝将网约车司机归类为企业雇员，由此规避福利开支与用人成本；亚马逊和谷歌等其他不少大型企业也在与工会组织持续斗争，避免因为薪酬和福利上调而拉高人力开销；甲骨文和 IBM 等公司则被指控限制或扣留销售佣金。另外，每家大厂的用工合同中都包含一系列复杂条款，确保雇主在弱势的员工面前保持优势地位。

很多企业忽视了公平交易，只想在法律或软件许可允许的范围内实现收益最大化。所以问题并不在花不花钱，而在于多数流行开源许可的约束力特别宽松，而且缺乏公共版权性质的互惠性条款。目前主流的 Apache 许可和 MIT 许可都是给得多、要的少，相当失衡。

Socket 开源开发者 Feross Aboukhadijeh 在采访邮件中表示，“开源维护者们创造了大量价值，但却几乎拿不到任何回报。目前支撑全球财富五百强企业业务的很多重要开源项目，都是由志愿者利用下班后的业余时间无偿维护的。”

Aboukhadijeh 表示，软件行业需要找到一种可行的方法，帮助维护者们拿到合理的、至少相当于一部分产出价值的回报。只有这样，他们才能继续编写新功能、修复 bug、改进文档质量，并及时修复关键安全问题。”

“我认为未来会有更多维护者选择较为严格的许可约束选项，限制企业使用其软件成果的方式与类型。如果双方不同协同一致，供给一侧终将陷入停滞，而我们也会身陷更多安全危机当中。”

Log4j 事件也证明大部分企业根本不会审查即将被引入应用程序的开源代码。Aboukhadijeh 补充道，“归根结底，企业有责任保证自己向应用程序中添加的一切代码均安全、可靠。”

开源软件的开放结果需要有人买单，如果不是善意支持的一方，那就必然是意图夺取开源控制权的另一方。

本文文字及图片出自 InfoQ