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

William Woodruff
2024年7月30日
研究实践

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

范围

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

• 本地参与者能否诱导公式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

页面内容
Homebrew
范围
重点发现
要点
最近文章
非传统创新者奖学金
在您的PajaMAS中劫持多代理系统
我们构建了MCP一直需要的安全层
利用废弃硬件中的零日漏洞
Inside EthCC[8]：成为智能合约审计员
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。