在过来的几天里，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），以查看是否能够在特定软件的上下文中触发某些开源组件中蕴含的易受攻击的代码，不管这些易受攻击的组件在盘根错节的依赖关系中藏的多隐秘。
参考链接：
- https://securityboulevard.com…
- https://www.endorlabs.com/blo…