在过去的几天里，Apache Commons Text 库中一个名为 Text4Shell 的新漏洞引起很大的轰动，该漏洞存在于 Apache Commons Text 1.5 到 1.9 版本中。此警报于 10 月 18 日发布，此前检测到大量试图利用 CVE-2022-42889 安全漏洞的攻击尝试，该漏洞通过 StringSubstitutor API 实现远程代码执行，其 CVSSv3 评分高达 9.8 分（满分 10 分）。为避免该漏洞关联的风险，企业需要使用可用的最新版本 Apache Commons Text 1.10.0，默认情况下禁用脚本插值。

Log4Shell 卷土重来了吗？

Text4Shell 之所以受到诸多关注是因为其名称与去年可怕的 Log4Shell 漏洞十分相似。Log4Shell 和 Text4Shell 都是在 java 开源项目中发现的。Text4Shell 漏洞的攻击方式是恶意攻击者通过利用漏洞，来使用专门为攻击设计的有效负载在易受攻击的应用程序中成功反向打开 shell，攻击者还可以通过 StringSubstitutor API 实现远程执行代码。

但是，StringSubstitution 不像 Log4j 那么普遍，目前有 2591 个项目使用受影响的 Apache Commons Text 库版本。这样看来，使用 Substitution 方法并且不清理不受信任的输入的项目并不多。同时为了让 Text4Shell 可被利用，必须要设置多个先决条件。加上没有清理输入的字符串替换方法并不是很常见的做法，可以说 Text4Shell 的风险比 Log4Shell 漏洞中的 Log4j 低得多。

开发人员在写代码时出现失误很正常的事情，也是意料之中的事，而在开源生态中，许多开源维护者和贡献者并不是专业的开发人员，因此错误难以避免。Text4Shell 给大多数公司带来的最大问题就是调查和补救漏洞所需要耗费的时间，因为大多数组织缺乏工具和技术来快速发现这种依赖关系的使用情况。在这个层面上，Text4Shell 和 Log4Shell 的比较是比较恰当的。要知道，美国安全审查委员会关于 Log4Shell 的最新报告指出美国政府共计投入了 33000 个小时来调查和响应 Log4Shell 漏洞！

虽然开源维护者也正在努力减少失误出现，但开源软件的最终用户始终需要投资于依赖软件生命周期管理解决方案，来帮助他们选择安全适当的依赖关系并给予有效保护。同时通过提高自动化程度，为快速调查和以高水平响应此类事件做好准备。

依赖项中的依赖关系

受影响依赖项的模糊性是关键挑战。开源组件中的漏洞的普遍难题和挑战是，大多数漏洞不会影响软件开发人员直接使用的组件（也就是依赖项）。取而代之的是，这些漏洞会影响开发人员使用的依赖项的依赖关系，这也使得开发人员很难评估漏洞对于其开发的软件是否真的很重要。在 Log4Shell 的案例中，Log4j 的流行是漏洞威胁的重要核心，可怕的是你可以在任何地方找到它。

更重要的是，Log4Shell 漏洞可能会影响为直接暴露于 Internet 的系统，攻击者可以将触发漏洞的恶意字符串或文本提交到一个系统，然后通过不同的数据库和系统传播，直到漏洞利用组织网络深处易受攻击的系统。Log4j 揭示了一个非常严峻的问题，即响应广泛存在的漏洞的费用通常比漏洞本身影响更大。

安全检查刻不容缓

在近期的一篇博客文章中（见参考链接 2）指出，平均每个企业都有超过 40000 个由开发人员直接下载的开源依赖项，而每个依赖项平均会带来 77 个其他的依赖项！这就会导致大规模且无法控制的依赖蔓延，同时也潜在地增加了企业攻击面。更重要也更令人担忧的是，企业中的安全团队通常对代码的使用位置和方式了解甚少，因此当漏洞被披露的时候，确定企业使用受到影响就像大海捞针一样难。

因此建议企业在应对此类问题的时候，可以尝试执行静态代码分析（SAST），以检查是否可以在特定软件的上下文中触发某些开源组件中包含的易受攻击的代码，不论这些易受攻击的组件在错综复杂的依赖关系中藏的多隐秘。

参考链接：

1. https://securityboulevard.com/2022/10/log4shell-spring4shell-and-now-text4shell/

2. https://www.endorlabs.com/blog/story-of-endorlabs