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

Trail of Bits博客
我们对Homebrew的审计
William Woodruff
2024年7月30日
research-practice

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

去年夏天，我们对Homebrew进行了审计。我们的审计范围包括Homebrew/brew本身（brew CLI的所在地），以及三个负责Homebrew操作中各种安全相关方面的相邻仓库：

• Homebrew/actions：一个包含在整个Homebrew CI/CD中使用的自定义GitHub Actions的仓库；
• Homebrew/formulae.brew.sh：负责Homebrew可安装包JSON索引的代码库；
• Homebrew/homebrew-test-bot：Homebrew的核心CI/CD编排和生命周期管理例程。

我们在Homebrew中发现了问题，虽然不严重，但可能允许攻击者在意外点加载可执行代码，并破坏Homebrew使用沙箱所意图的完整性保证。同样，我们在Homebrew的CI/CD中发现了问题，可能允许攻击者秘密修改公式的二进制（“bottle”）构建，并可能从触发CI/CD工作流转向控制CI/CD工作流的执行并窃取其机密。

此次审计由Open Tech Fund赞助，作为他们保护互联网基础设施关键部分更大使命的一部分。您可以在我们的出版物仓库中阅读完整报告。

Homebrew

Homebrew是自称为“macOS（或Linux）缺失的包管理器”。它作为macOS上软件开发人员的事实标准包管理器，每年服务数亿次包安装。这些安装包括Golang、Node.js和OpenSSL等“关键”包，使得Homebrew的安全性（及其构建的完整性）对整个下游软件生态系统的安全至关重要。Homebrew的核心（不要与homebrew-core混淆）是一个Ruby单体，负责向用户提供brew CLI以及可导入的Ruby API。

自2009年成立以来，Homebrew经历了多次架构转变，旨在提高向用户交付包的可靠性和可用性：实现了二进制构建（bottles），使其成为默认安装机制（取代本地源代码构建），并随后仅在CI/CD上构建，以限制开发者机器被入侵的风险。尽管采取了这种日益静态的方法，Homebrew的核心代码库本质上是动态的，并且在许多地方反映了Homebrew历史上需要通过用户控制的Ruby代码动态加载DSL指定公式的需求。

范围

Homebrew既是一个用户可安装的包管理器（brew CLI），也是一个打包生态系统，具有广泛且定制的CI/CD配置，用于审查、构建和向最终用户分发bottles。我们的审计侧重于这两方面的内容，并旨在回答以下（但不限于）问题：

• 本地参与者能否诱导公式DSL的意外执行，例如在没有明确调用brew install的情况下？
• 本地参与者能否诱导tap公式的意外评估，例如仅通过brew tap而没有后续用户操作？
• 本地参与者能否在brew内诱导命名空间混淆或冲突，导致brew install foo安装意外公式？
• 本地安装的公式能否秘密颠覆或绕过Homebrew的构建隔离机制？
• 无特权或低特权CI/CD参与者（如第三方贡献者）能否在Homebrew的CI/CD中转向更高特权？
• 无特权或低特权CI/CD参与者能否秘密污染或破坏bottle构建？
• 无特权或低特权CI/CD参与者能否在Homebrew的CI/CD中建立持久性？

重点发现

brew

在我们审查brew CLI代码库的过程中，我们发现了一些发现，虽然不严重，但可能破坏Homebrew的每个公式完整性和隔离属性。我们还发现了可能允许从意外源（如远程URL）加载公式（即可执行代码）的发现。

一些值得关注的发现包括：

• TOB-BREW-2：公式可以通过字符串注入影响其沙箱的构建，导致沙箱逃逸。
• TOB-BREW-5：Homebrew使用易碰撞的哈希函数（MD5）用于合成命名空间（FormulaNamespace），可能允许攻击者诱导公式之间的运行时混淆。
• TOB-BREW-8：公式可以秘密地在构建中包含网络资源，而无需通过resource节明确列出它们。
• TOB-BREW-11：公式可能使用套接字转向在macOS上逃脱其构建沙箱。
• TOB-BREW-12：公式可能通过用户先前激活的sudo令牌机会性地执行权限提升。
• TOB-BREW-13：可以诱导brew install从非本地URL安装公式，适用于所用curl版本支持的任何协议，如SFTP或SCP。

我们对Homebrew/brew的总体评估反映在我们的报告中：虽然经过广泛测试，但Homebrew的大型API和CLI表面以及非正式的本地行为合约为机会主义攻击者提供了多种非沙箱本地代码执行的途径。这些途径不一定违反Homebrew的核心安全假设（假设公式可信），但可能被恶意公式或通过意外的公式加载源（如未充分清理的输入）颠覆。

Homebrew的CI/CD

我们对Homebrew的CI/CD工作流和actions的审查发现了可能破坏Homebrew CI/CD运行完整性并允许低特权用户转向更高特权位置甚至获得在Homebrew自托管GitHub Actions运行器上持久性的发现。

一些值得关注的发现包括：

• TOB-BREW-18：多个CI/CD工作流使用pull_request_target触发器允许第三方拉取请求在Homebrew上游仓库的上下文中运行代码，可能启用凭据披露或篡改Homebrew的bottle构建。
• TOB-BREW-23：多个CI/CD工作流无意中允许通过未清理的workflow_dispatch输入进行shell注入，可能允许低特权用户（即可以分派工作流但无法修改它们的用户）进行垂直移动。

除了CI/CD特定发现外，许多brew发现在CI/CD设置中也很突出：

• TOB-BREW-6：描述了在存档提取期间缺乏沙箱/隔离，可能被低特权CI参与者用于通过诱导提取在CI生命周期中自动加载和执行公式或其他可执行代码来转向更高特权上下文。
• TOB-BREW-13：如上所述，可能被低特权CI参与者用于通过诱导通过brew install安装不在CI预配置（假定可信）上下文中的公式来转向更高特权上下文。

我们的报告得出结论，Homebrew的CI/CD虽然成熟且有效减少了Homebrew包生命周期中的人工接触点，但复杂且依赖于GitHub Actions工作流中常见的易误用模式（如危险的工作流触发器和通过模板扩展混合配置、代码和数据）。这些模式不一定允许完全外部参与者持久化或转向，但可能被低特权内部人员（如恶意维护者）利用来破坏Homebrew CI/CD所做的完整性和隔离假设。

要点

审计像Homebrew这样的包管理生态系统带来了独特的挑战。本地包管理工具设计上安装和执行任意第三方代码，因此通常在预期和意外代码执行之间具有非正式和松散定义的边界。这在像Homebrew这样的打包生态系统中尤其如此，其中包的“载体”格式（公式）本身是可执行代码（在Homebrew的情况下是Ruby脚本）。

在整个审计过程中，我们与Homebrew维护者和Homebrew PLC密切合作，并感谢他们分享广泛的知识和专业知识。我们还要特别感谢Homebrew的安全经理Patrick Linnane，他代表Homebrew进行了分类和协调工作。

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

页面内容
近期文章
使用Deptective调查您的依赖项
系好安全带，Buttercup，AIxCC的评分回合正在进行中！
将您的智能合约成熟到超越私钥风险
Go解析器中意外的安全陷阱
我们从审查Silence Laboratories的23个库中的第一个DKL中学到了什么
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。