对 PyTorch 的供应链攻击

原文 ↗ Hacker News 讨论 ↗

PyTorch 的 GitHub Actions 管线最近出现的供应链漏洞凸显出，一个微不足道的文档修复就可能授予足够的贡献者权限，从而在具有特权的自托管 CI runner 上运行任意代码，并可能通过被篡改的发布版本影响下游用户。评论者就 5000 美元的漏洞赏金是否足以对应这种问题、黑市上这类利用手法的实际价值，以及研究过程中“实际利用”的法律灰色地带展开了讨论。对话的大部分内容集中在更广泛的 CI/CD 和生态系统风险上——过度依赖第三方包、非短生命周期 runner、过于宽松的 GitHub 令牌——以及具体缓解措施，如 runner 的短生命周期隔离、严格的权限范围、依赖固定和代码审计。

PyTorch 供应链漏洞的性质

  • 攻击依赖于 GitHub Actions 和具有广泛权限的自托管 runner。
  • 任何“贡献者”都可以通过 PR 在这些 runner 上自动运行工作流。
  • 研究人员通过一个微不足道的拼写修复成为贡献者，随后在一台 GPU runner 上实现了远程代码执行、持久化和 root 权限。
  • 从那里，他们可以（原则上）篡改官方构建，或等待被攻陷主机上的特权活动。

GitHub Actions、自托管 runner 与权限

  • 许多人认为 GitHub 默认允许“贡献者”PR 自动进入 CI 的做法并不安全；建议包括按用户显式启用，以及按次运行审批。
  • 关键区别在于：GitHub 托管的短生命周期 runner 更安全；持久的自托管 runner 使跨构建令牌窃取和横向移动成为可能。
  • GITHUB_TOKEN 权限以及配置过高权限的个人访问令牌被强调为常见的升级路径。
  • 人们反复建议使用短生命周期 runner（VM、Kubernetes、自动扩缩容工具）以及严格“默认只读”的工作流权限。

漏洞赏金价值与经济性

  • 一些人认为 5000 美元的奖励相对于潜在影响来说太低；另一些人则认为，大多数漏洞在“黑市”上几乎没有价值，除非它们符合既定的、可变现的模式。
  • 合法、干净的赏金收入被认为相较于更难变现的非法利用手段具有溢价。
  • 有人指出，项目可能会按漏洞类别设定奖励上限，并且必须避免变成“美元皮纳塔”。

法律与伦理问题

  • 有人担心，这项研究涉及对生产工作流的真实修改（例如重命名发布），而这通常被许多赏金规则所禁止。
  • 讨论了“安全港”政策，以及即使行为负责也可能面临法律威胁的风险。
  • 普遍表达的规范是：即便在实践中有用，通过更深入的利用来展示完整影响通常也不被鼓励。

供应链风险、依赖与缓解措施

  • 评论者将此事与对 pip/npm 生态和微小包的更广泛过度依赖联系起来；C 语言生态被视为更保守，但并非没有风险。
  • 建议的防御措施：
    • 固定版本和哈希；避免从会变化的分支拉取。
    • 对依赖进行供应化或镜像；使用企业代理和允许列表。
    • 审查实际制品，而不只是 GitHub 源码；目标是可复现构建以及来源/证明。
    • 在可行情况下，优先使用隔离式或空气隔离的 CI。

CI/CD 卫生与平台问题

  • 来自其他项目的例子展示了更好的做法：未获批准的 PR 不运行 CI，对可疑用户立即停用账号。
  • 批评指出，GitHub 自己的 runner 镜像会从供应商站点拉取许多未固定版本的工具，形成巨大的攻击面。
  • 一些人认为 PyTorch 的 70 多个 GitHub 工作流以及与专有 GitHub 技术的深度纠缠，是一个结构性的透明度和控制问题。

更广泛的影响

  • 有人指出，重大国防和航空航天承包商等组织也依赖这些生态系统，这引发了国家安全方面的担忧。
  • 一些人认为 PyTorch 现在“更像一个 API，而不是一个实现”，并预计随着时间推移会迁移到更小、可审计性更强的张量库。
  • 有评论者质疑“好人先到一步”的说法，指出这在根本上是无法验证的。