Rust供应链攻击危及Solana相关构建管道

攻击无需下游漏洞即可触发

根据原始报告，只需拉取受污染的依赖并运行 Cargo 构建，就足以触发远程载荷。这意味着风险从应用的可利用性转移到了开发者工作站和持续集成环境——而这些环境通常存放着密钥、签名凭据和基础设施访问权限。

来自 SlowMist、Socket 和 StepSecurity 的安全研究人员发现了 arrayref@0.3.10、internment@0.8.7 和 append-only-vec@0.1.9 的恶意版本。这些被污染的包引入了一个拼写错误劫持的 proc-macro 依赖。在 Cargo 构建过程中，该依赖的构建脚本会在许多团队甚至尚未检查代码之前，就并执行远程载荷。

Rust 安全团队移除了这些恶意版本，并锁定了维护者账户，指出维护者的机器或发布凭据很可能已被入侵。这一细节至关重要，因为它意味着攻击面并非 crate 代码中的一次性技术缺陷，而是包供应链内部的账户级漏洞。

为何 Solana 的暴露使情况不同

arrayref 在 Rust 生态系统中广泛使用，包括涉及 Solana 相关组件的依赖链。这些 crate 出现在项目依赖图中，并不意味下游项目已被攻破。但这确实意味着许多团队必须紧急审计其 lockfile 和构建日志，因为恶意版本可能通过传递性依赖进入项目，而无需直接更新。

Solana 一直是开发者活动最活跃的区块链生态系统之一。一个位于依赖树底部的被污染 crate，可以潜藏在钱包、验证器、索引器和 DeFi 接口中，而下游应用不会出现任何可见变化。

更大的担忧不在于哪个特定项目发布了恶意二进制文件，而在于加密货币基础设施中有多少依赖共享的开源包表。一个被入侵的维护者账户可以通过构建图在多个团队和产品之间传播。对于安全团队而言，当前的首要任务是检查 Cargo.lock 文件中是否包含这三个恶意版本，并检查 CI 运行器是否存在异常的外连流量。

使响应复杂化的一个因素是版本移除与本地清理之间的时间差。包注册表可以快速取消发布恶意版本，但这不会重写开发者机器上的 Cargo.lock 文件，也不会重建已交付的容器。在 CI 中使用缓存依赖进行构建的团队，除非主动刷新 lockfile，否则可能不会拉取干净版本。这种操作延迟给了攻击者一个窗口期，即便公共安全公告已经发布，他们仍可继续使用窃取的凭据。

构建时攻击在代码审查之前就已发生

构建脚本处于危险位置，因为它们在编译时执行。在这个案例中，拼写错误劫持的依赖不仅仅是命名技巧。它利用构建阶段来获取并运行远程载荷，这意味着恶意行为在代码被审查之前就已经执行。

本文标签：

声明：本文由代码号注册/游客用户【澜漪】供稿发布，本站不对用户发布的Rust供应链攻击危及Solana相关构建管道信息内容原创度和真实性等负责。如内容侵犯您的版权或其他权益，请留言并加以说明。站长审查之后若情况属实会及时为您删除。

很赞哦！ ()