漏洞10年深藏不露，PHP 项目依赖关系管理工具Composer安全吗？-CSDN博客

聚焦源代码安全，网罗国内外最新资讯！

专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

说到PHP，无需多言，Composer 就是御用软件包管理器。它快速、易用、维护活跃而且非常安全，至少多数人是这么想的。

2021年4月21日，Composer 中被发现命令注入漏洞，震惊了整个 PHP 社区。好在它并没有带来多大的影响，但它具备这个能力。该漏洞的问题在于，它影响的是 Composer 供应链的最核心部分：Packagist 服务器。

要不是及时发现了这个漏洞，后果将不堪设想，因为 PHP 支持着80%的 web 且它们多数使用的就是 Composer。

如 Packagist 服务器受陷，则可导致维护人员的凭据遭泄露或者下载内容被重定向到恶意服务器，导致难以预测的行为如蠕虫传播、后门等。好在，Composer 和 Packagist 的维护人员立即响应，在12小时内修复该问题。目前并未发现该漏洞遭利用的迹象。

但美中不足的一点是，虽然多数基于 php 的项目使用的是公开库 (packagist.org)，但也存在被私下托管的可能性。如果私营组织机构出现了这个情况，则Packagist 的维护人员显然无法应用修复方案。

如何在 Packagist 服务器上执行恶意代码？

要了解如何在 Packagist 服务器上执行恶意代码，必须懂一点 Composer 的内部运行原理。

Composer 是一个 Php 脚本，必须出现在托管着Php 项目的且依赖它管理依赖关系的所有服务器中。部署应用程序新版本后，必须提取依赖关系。在实践中，这就意味着调用一个 Composer 命令——composer install 的某种变体。当要求安装新的软件包时，Composer 就会联系仓库（很可能是 https://packagist.org）查找集成到项目中的库的元数据。

该元数据的一个重要内容是库代码的 URL，它将被下载并本地存储在 vendor/sub-directory中。该RUL 一般指向一个 CVS，如：

{


            “name”: “abdielcs/expanded-collection-bundle”,


            “version”: “v0.1.2”,


            “source”: {


                “type”: “git”,


                “url”: “https://github.com/abdielcs/ExpandedCollectionBundle.git”,


                “reference”: “3e535cee26825982f9b60d1ffb72a0ddccb6b542”


            }


}

上述 json 结构是 Packagist 按照包含 abdielcs/expanded-collection-bundle 的库请求返回的。其中，它告知本地 Composer 安装程序从属性 url 指向的 URL 中找到的仓库中查看，本案例中为：

https://github.com/abdielcs/ExpandedCollectionBundle.git.

由此可见，Packagist 仅仅是元数据仓库，实际托管库代码是每个个体维护人员的责任。因此，Packagist 作为庞大的目录，以某种方式将包名称翻译为下载URL。

由于 Packagist 是一个公开目录，因此任何人都能轻松上传新包，实际上只要有邮件地址就能上传。而这正是它快速增长并流行起来的原因。但同时它也带来了漏洞。Packagist 不会执行很多验证，而只是验证json结构是正确的，这就可疑在“来源”定义中放置除了 URL 的东西。当然 Composer 脚本确实对 URL 进行了一些清理，但最终该信息直接进入外部VCS命令，从而带来了利用机会。

恶意命令注入通过未验证选项完成，如：

return ‘git ls-remote –heads ‘ . ProcessExecutor::escape($url);

在本例中，git 被调用为操作系统命令，而外部输入 ($url) 得到正确清理。

但，如果url 以 “-“ 开头呢？

在本例中，实际被调用的真正命令并非开发人员预想的，而这就是问题浮现的地方。当 Packagist 发现新软件包时会立即查询仓库URL，以获得一些基础信息并让所有人知晓。这意味着如果 URL 中包含恶意代码，则将在 Packagist 上执行，而研究员 Thomas Chauchefoin 就是这么做的。

使用构造精良的源URL，再结合 Mercurial 不太知名的特性，Thomas 及其团队可在 Packagist 服务器上执行任意命令，有效地证实了它的可行性。

而有意思的是，该漏洞在十多年前就已经出现了！

为何之前未测出？

漏洞存在如此长的时间说明了“参数注入”类威胁的隐秘性。不过防御此类威胁的最佳方式仍然是避免执行从包含用户提供输入的字符串创建的外部命令。

然而，在本例中尚不清楚，既然Composer 的其中一个目标是 VCS （版本控制系统）独立，为何会产生这类漏洞。因此，考虑到多个 VCS 版本的存在，可能并非每个版本都是原生的PHP实现。

结论

随着软件开发流程变得愈加复杂，覆盖开源供应链中的每个阶段极其困难。如果项目规模庞大，它们多数一定会依赖于可被攻陷的第三方组件。本文提到的 Composer 漏洞就说明了用于管理此类依赖关系的工具也可能易受攻击。

确保自己安全的最佳方法就是依靠自动化工具监控并尽快提供安全漏洞警报，而奇安信开源卫士就是这样一款工具。

【开奖啦！！！！！】

限时赠书|《软件供应链安全—源代码缺陷实例剖析》新书上市

上次的限时赠书活动中奖名单已出炉，恭喜以下同学中奖，请未填写地址的同学在微信后台私信地址，我们已经发出部分书籍啦。

@whyseu @。@HFwuhome@惊蛰 @nimo @XuZ @淡然 @Marco韬 @王孟 @Wecat@nwnλ @MOBE @湘北二两西香葱@※ @搬砖小土妞@云烟过眼 @r00t@小风 @傲雪@最好走的路是套路 @Zhao.xiaojun @浅笑淡然 @X-Star @Erick2013 @小秦同学 @X @王骏 @欢寻 @nbp@Mr. Guo

大家可移步京东电子工业出版社一睹为快！或直接点击“原文链接”购买。