PyPI安全审计:揭示代码仓库与部署系统的潜在风险

本文详细介绍了对Python包索引PyPI及其部署系统cabotage的安全审计过程,发现了多个可能影响系统完整性和可用性的中危漏洞,包括AWS SNS集成弱点、信息泄露和密码哈希问题,并提供了修复建议和行业最佳实践。

我们对PyPI的审计 - Trail of Bits博客

William Woodruff
2023年11月14日
开源, 供应链, 生态系统安全, 审计

这是一篇与PyPI维护者联合发布的文章;请在此处阅读他们的公告!

本次审计由开放技术基金赞助,作为其保护互联网关键基础设施更大使命的一部分。您可以在我们的出版物仓库中阅读完整报告。

今年夏末,我们对Warehouse和cabotage进行了审计,这两个代码库分别负责PyPI的运行和部署。我们的审查发现了多项发现,虽然不关键,但可能危及两者的完整性和可用性。这些发现反映了大系统中的更广泛趋势:安全问题主要对应于服务交互的地方,特别是那些服务合同规范不足或薄弱的地方。

PyPI

PyPI是Python包索引:Python生态系统的官方和主要包装索引和仓库。它托管了由75万唯一用户上传的50万个独特Python包,每月服务超过260亿次下载。(这相当于地球上每个人每月超过三次下载!)

因此,PyPI托发的发行版基本上是几乎所有用Python编写的程序的真实来源。此外,PyPI在全球范围内广泛镜像,包括互联网访问受限或受监控的国家。

2018年之前,PyPI是一个大型独立的遗留应用程序,具有近二十年功能增长积累的显著技术债务。从2016年到2018年进行了广泛的重写,最终推出了Warehouse的普遍可用性,这是当前支持PyPI的代码库。

此后进行了各种重要的功能增强,包括添加范围API令牌、基于TOTP和WebAuthn的MFA、组织账户、秘密扫描和可信发布。

我们的审计和发现

在底层,PyPI由多个组件构建,包括本身托管在PyPI上的第三方依赖项。我们的审计专注于其两个最核心的组件:

  • Warehouse:PyPI的“核心”后端和前端,包括pypi.org上的大多数公开可访问视图,以及PEP 503索引、公共REST和XML-RPC API和管理员界面
  • cabotage:PyPI的持续部署基础设施,使PyPI管理员能够进行GitOps风格的部署

Warehouse

我们对Warehouse的代码库进行了全面审计,包括提供给浏览器客户端的相对少量的JavaScript。一些特别关注的领域包括:

  • “传统”上传端点,目前是包提交到PyPI的主要上传机制;
  • 管理员界面,允许具有管理员权限的用户在生产PyPI实例上执行破坏性和敏感操作;
  • 所有用户和项目管理视图,允许其各自特权用户对PyPI用户账户和项目状态执行破坏性和敏感操作;
  • Warehouse的AuthN、AuthZ、权限和ACL方案,包括不同凭据(例如密码、API令牌、OIDC凭据)的处理和充分权限;
  • 第三方服务集成,包括与GitHub秘密扫描、PyPA咨询数据库、通过AWS SNS的电子邮件传递和状态管理以及外部对象存储(Backblaze B2、AWS S3)的集成;
  • 所有登录和身份验证流程,包括基于TOTP和WebAuthn的MFA流程以及账户恢复和密码重置流程。

在我们的审查过程中,我们发现了多项发现,虽然不关键,但可能危及Warehouse的可用性、完整性或其托管发行版的完整性。我们还发现了一个可能允许攻击者披露通常私有账户信息的发现。经过审计后的修复审查,我们相信这些发现中的每一个都已得到充分缓解,或者不会对PyPI的操作构成直接风险。

有趣的发现包括:

  • TOB-PYPI-2:弱签名验证可能允许攻击者操纵PyPI的AWS SNS集成,包括针对单个用户电子邮件的主题订阅和退回/投诉通知。
  • TOB-PYPI-5:攻击者可以使用上传端点的意外信息泄露作为侦察预言机,确定账户有效性而不触发普通登录尝试事件。
  • TOB-PYPI-14:访问PyPI的一个或多个对象存储服务的攻击者可能由于弱密码哈希导致缓存中毒或混淆。

我们对Warehouse的总体评估反映在我们的报告中:Warehouse的设计和开发实践符合行业标准最佳实践,包括强制执行通常具有抱负的实践,如100%分支覆盖、自动质量和安全linting以及依赖项更新。

cabotage

与Warehouse一样,我们对cabotage的审计是全面的。一些特别关注的领域包括:

  • GitHub webhook和事件负载的处理,包括基于GitHub事件的容器和构建调度逻辑;
  • 容器和镜像构建与编排;
  • 秘密处理和日志过滤;
  • 面向用户的cabotage Web应用程序,包括所有表单和路由逻辑。

在我们的审查过程中,我们发现了多项发现,虽然不关键,但可能危及cabotage的可用性和完整性,以及它构建和部署的容器的可用性和完整性。我们还发现了两个可能允许攻击者绕过普通访问控制或日志过滤机制的发现。经过审计后的修复审查,我们相信这些发现已得到充分缓解,或者不会对PyPI的操作(或通过cabotage部署的其他应用程序)构成直接风险。

有趣的发现包括:

  • TOB-PYPI-17:具有cabotage构建权限的攻击者可能通过命令注入转向对Caborage本身的背板控制。
  • TOB-PYPI-19:具有cabotage构建权限的攻击者可能通过精心制作的主机应用程序Procfile转向对cabotage本身的背板控制。
  • TOB-PYPI-20:具有cabotage部署权限的攻击者可能由于GitHub提交冒充而部署看起来合法但不真实的镜像。

从报告中,我们的总体评估是cabotage的代码库不如Warehouse成熟。特别是,我们的评估反映了与Warehouse不共享的操作缺陷:cabotage有一个活跃的维护者,可用的公共文档有限,没有完整的单元测试套件,并且不使用CI/CD系统自动运行测试或评估代码质量指标。

要点

单元测试、自动linting和代码扫描都是安全软件开发生命周期中的必要组成部分。同时,正如我们的完整报告所示,它们不能保证系统或设计的安全性:手动代码审查对于捕获过程间和系统级缺陷仍然非常宝贵。

我们在整个审计过程中与PyPI维护者和管理员密切合作,并感谢他们分享广泛的知识和专业知识,以及积极分类提交给他们的报告。特别是,我们要感谢现任PyPI安全工程师Mike Fiedler,感谢他在参与期间之前、期间和之后的文档和分类工作。

如果您喜欢这篇文章,请分享: Twitter LinkedIn GitHub Mastodon Hacker News

页面内容
PyPI
我们的审计和发现
要点
最近帖子
Trail of Bits的Buttercup在AIxCC挑战中获得第二名
Buttercup现已开源!
AIxCC决赛:记录表
攻击者的提示注入工程:利用GitHub Copilot
作为新员工发现NVIDIA Triton中的内存损坏
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计