四大编码代理供应商的7个沙箱逃逸漏洞

# 沙箱逃逸周 来源：https://www.pillar.security/blog/the-week-of-sandbox-escapes *为什么代理式安全需要自己的威胁模型* ## 执行摘要 在几个月的时间里，Pillar Research 发现并复现了 Cursor、Codex、Gemini CLI 和 Antigravity 中的沙箱逃逸和边界绕过。在几乎所有案例中，代理并不需要直接突破沙箱。它只需编写一些内容，这些内容随后会被沙箱外部的受信任组件运行、加载、扫描或视为安全。总体而言，这些漏洞表明 AI 编程代理改变了终端的威胁模型，并且大多数沙箱设计尚未跟上这一变化。 我们以**沙箱逃逸周**的形式发布这项研究：每天一篇深度剖析，每篇展示一种跨越边界的不同路径。这些发现可归纳为四种可重复的失效模式： - 无法跟上操作系统复杂性的黑名单沙箱 - 实际上是可执行代码的工作区配置 - “安全”命令白名单信任命令名称而非调用方式 - 完全位于沙箱外部的特权本地守护进程 底线是：代理的爆炸半径不仅仅是代理进程本身；它还包括代理能够编写的、宿主机后来会信任的一切内容。 代理带来的生产力提升是真实存在的，开发者已经在使用它们。问题在于，这些工具在大多数组织将其作为基础设施进行治理之前，就已经成为了基础设施。 CISO 和安全采购人员需要认识到，仅仅让一个代理式 IDE 或 CLI 拥有沙箱是不够的。它需要证明沙箱边界究竟在哪里、代理能编写什么、宿主机哪些组件信任这些写入、它能访问哪些本地守护进程、哪些命令跳过审批、以及当受信任的辅助程序执行了代理影响的内容时，存在哪些遥测数据。 代理式工具正在成为终端行为体。它们需要像终端行为体一样被评估、监控和治理。 ## Pillar 的方法 在 Pillar，我们从企业风险的角度审视 AI 的采用。 代理式编码工具是一个自然的起点，因为它们将终端风险集中在一个工作流中。它们运行的场所，源代码、SSH 密钥、云令牌、浏览器会话、包发布权限和生产访问权限往往紧密相邻。它们经常处理不受信任的输入：README、问题、文档、依赖项、代码注释、差异、日志和网页内容。它们生来就是为了行动，而不仅仅是回答问题。 把这些结合起来，提示注入就不再是一个聊天机器人问题。恶意指令可以转化为开发者机器上的本地操作。 大多数产品通过沙箱、审批提示和“安全命令”策略来解决这种风险，但这些控制通常只关注代理进程本身。代理的能力还包括它能编写的文件，以及后来信任这些文件的宿主机组件。 ## 代理如何逃逸其沙箱 沙箱的一般规则是：工作区内部是允许的，工作区外部是受保护的。 实际上，沙箱边界至少有三层： - **直接执行：** 代理进程可以运行什么。 - **工作区写入：** 代理可以创建或更改哪些文件。 - **宿主机信任：** 未沙箱化的组件之后如何处理这些文件。 **第三层是最有趣的失效所在。** 现代 IDE 和 CLI 充满了宿主机端的自动化功能： - Python 扩展发现解释器 - Git 集成扫描仓库 - VSCode 任务运行器加载项目任务 - Hook 引擎触发生命周期命令 - Docker Desktop 暴露强大的本地套接字 一个沙箱化的代理可以遵守所有规则，同时仍然能够塑造这些组件所消费的输入。 这就是想象中的或感知到的边界：相信“代理只能写入项目内部”等同于“代理无法影响宿主机”。 但这是一个错误的假设。**在开发者终端上，项目文件往往是可执行的基础设施。** ## 系列文章 | 文章 | 平台 | 边界如何失效 | 状态 / 公告 | 链接 | |------|------|--------------|--------------|------| | 逃逸 Antigravity 的“默认允许”安全约束 | Antigravity | 一个黑名单风格的 macOS Seatbelt 配置文件使得某些 OS 特性可被访问，从而允许在沙箱外部执行。 | 被判定为正常 Google 应用。漏洞类别为“其他有效安全漏洞”。我们进行了降级，认为该问题难以利用（需要社会工程或信任包含间接提示注入的仓库）。Antigravity 反馈：“这份报告质量卓越！” | 阅读文章 (https://www.pillar.security/blog/escaping-antigravitys-allow-default-seatbelt) | | 一个 Docker 套接字统治一切 | Codex, Cursor, Gemini CLI | 一个特权本地守护进程成为未沙箱化的执行环境，可被原本受限的代理访问。 | 问题已修复，公告：GHSA-v4xv-rqh3-w9mc (https://github.com/cursor/cursor/security/advisories/GHSA-v4xv-rqh3-w9mc) | 阅读文章 (https://www.pillar.security/blog/one-docker-socket-to-rule-them-all-escaping-codex-cursor-and-gemini-clis-sandboxes) | | 沙箱让我编辑了 venv，然后其他程序运行了它 | Cursor | 代理修改了一个 virtualenv 解释器，随后 Cursor 的未沙箱化 Python 扩展在发现过程中执行了它。 | 问题已修复，公告：GHSA-p9g2-cr55-cw9c (https://github.com/cursor/cursor/security/advisories/GHSA-p9g2-cr55-cw9c)。 | 阅读文章 (https://www.pillar.security/blog/the-sandbox-let-me-edit-a-venv-and-something-else-ran-it) | | Git 目录不一定非要叫 .git | Cursor | Git 元数据的间接引用绕过了基于路径的沙箱规则，Git 扩展通过 fsmonitor 触发了执行。 | 问题已在 3.0.0 中修补，等待 CVE | 阅读文章 (https://www.pillar.security/blog/git-directories-do-not-have-to-be-called-git) | | GitPwned：从白名单到 RCE | Codex CLI | “安全命令”白名单信任了命令名称，但没有建模危险参数和 Git 副作用。 | 问题已在 v0.95.0 中修补，已获得高严重性漏洞赏金，等待 CVE | 阅读文章 (https://www.pillar.security/blog/gitpwned-allowlist-to-rce) | | Hook 已经在工作区中 | Cursor | 工作区控制的 .claudehook 配置变成了未沙箱化的命令执行。 | 问题已在 3.0.0 中修补，CVE-2026-48124；跟踪于 GHSA-pc9j-3qc2-95wv (https://github.com/cursor/cursor/security/advisories/GHSA-pc9j-3qc2-95wv)。 | 阅读文章 (https://www.pillar.security/blog/the-hook-was-already-in-the-workspace) | | .vscode 中的定时炸弹：绕过 Antigravity 的安全模式 | Antigravity | 代理编写了一个 VSCode 任务配置，宿主机随后自行运行了它。 | 判定理由：正常 Google 应用。漏洞类别为“其他有效安全漏洞”（沙箱绕过）。我们进行了降级，认为该问题难以利用。这份报告质量卓越。 | 阅读文章 | 每篇文章深入探讨一条攻击链。它们共同显示了相同的失败模式在多个供应商和产品中反复出现。 ## 失败模式 1：黑名单不敌平台复杂性 Antigravity Seatbelt 的发现是黑名单失败最清晰的例子。一个从“默认允许”开始的沙箱配置文件必须记住操作系统暴露的每一个危险操作：每个本地服务、挂载类型、启动路径以及它们之间奇怪的交互。 **这不是一个沙箱，而是一份某人记得要阻止的东西的列表，而且总是缺少一项。** 代理使情况变得更糟，因为攻击者在环境内部获得了一个灵活的操作者。模型可以适应、编写文件、运行命令、重试，并以静态策略未能预料的方式组合功能。 ## 失败模式 2：工作区配置常常就是代码 几个发现并非经典的进程逃逸。代理编写了它被允许编写的文件。逃逸发生在之后，当宿主机将这些文件视为受信任的配置时。 我们在“.vscode 中的定时炸弹：绕过 Antigravity 的安全模式”、“Hook 已经在工作区中”漏洞、virtualenv 解释器、Git 配置和 fsmonitor 辅助程序中看到了这一点。 值得注意的是，这些都是正常的开发者工作流程。多年来，项目配置一直在告诉机器如何构建、测试、启动、检查和自动化一个仓库。**当一个沙箱化的写入者可以将可执行配置交给一个未沙箱化的读取者时，边界就有了漏洞。** 代理打破了旧的假设，即这些配置是由人类编写并以常规方式审查的。开发者越早适应这一现实越好。 ## 失败模式 3：“安全”命令按名称并不安全 **Codex 的 git show 发现之所以被允许，是因为该名称看起来是只读的。但实际的调用并非如此。** Git 充满了可以改变行为的标志。一个命令可能看起来无害，但仍然可以写入文件、加载配置、调用辅助程序、运行钩子或触发用户定义的行为。在这种世界里，按命令名称进行白名单处理过于粗糙。 策略问题不是“git show 安全吗？”而是：正在运行的具体调用是什么，带有什么参数，在什么目录下，针对什么配置，以及可能产生什么副作用？ ## 失败模式 4：本地守护进程存在于沙箱之外 **Docker 套接字的发现提醒我们，对代理进程进行沙箱化并不等于对宿主机进行沙箱化。** 一个特权本地守护进程是一个第二执行环境。如果代理可以与之通信，该守护进程就可以做代理本身不被允许做的工作。开发者终端通常运行 Docker Desktop、包管理器、云 CLI、语言服务器、构建守护进程、模拟器和本地数据库。其中任何一个都可能成为信任桥接。 一个沙箱如果阻止直接的文件系统写入，但保留了一个具有宿主机访问权限的守护进程，那么它并没有保护宿主机。它只是将边界移动到了守护进程的 API。 ## 安全团队应向编码供应商提出的问题 采购对话不应停留在“它有没有沙箱？”对于代理式系统，必须问的问题包括： - 代理可以编写什么？ - 哪些宿主机组件信任这些写入？ - 代理可以访问哪些本地守护进程？ - 哪些命令跳过审批，为什么？ - 策略是在命令名称、路径还是实际副作用上执行的？ - 产品能否区分用户创建的项目状态和代理创建的项目状态？ - 当受信任的辅助程序运行代理编写的内容时，会触发哪些遥测？ 这些问题能够区分出：一个沙箱是营销文稿中的复选框功能，还是一个在宿主机上为保护代理式进程提供可执行边界的真正机制。 ## Pillar 的方法 我们的方法始于代理式威胁建模。某种东西向代理发送不受信任的输入，代理产生输出，其他组件消费该输出并据此行动。系统中大多数其他组件在代理存在之前就已经构建好了。如果一项控制只关注代理进程，那么它只保护了那条链中的一个环节。因此，我们对任何代理式系统都会提出以下问题： - 哪些不受信任的输入可以到达模型？ - 模型可以直接做什么？ - 代理可以编写什么？ - 哪些组件读取这些写入？ - 其中哪些组件在代理的策略之外执行代码？ - 哪些控制是确定性的，哪些依赖于模型行为？ - 哪里可以让代理创建的工件变成宿主机上的一个动作？ 在建模终端时，我们将其视为一组信任交接点，而不是一个单一的进程树。代理将工作交接给在 CI、浏览器、SaaS 工作流和开发者机器上信任它的系统。 我们通过关注这些交接点没有扼流点的地方来构建我们的终端解决方案。在 CI 中，一个消费代理输出的构建步骤运行在你可以记录日志的地方。在 SaaS 中，交接点跨越一个你已经在监控的 API。在开发者机器上，代理写入一个文件，一个特权本地进程在微秒后拾取它，在同一个用户会话中，没有网络跳转，没有任何东西监视这个接缝。这个交接点默认是不可见的。 这就是我们的终端产品所检测的对象：接缝本身。不是代理进程，不是危险文件名列表。而是代理所写内容的来源、哪个未沙箱化的组件读取了它的可见性，以及当执行发生时留下的记录。 这个系列中的每一次逃逸都产生了这个序列。我们不需要事先知道 fsmonitor 是有趣的。 ## 代理的良好威胁模型是什么样的 代理式终端需要一个分层威胁模型。相关的控制措施应属于组织防御的所有层面：供应商产品、企业策略以及围绕工具的终端安全层： - 在沙箱使用处从“默认拒绝”开始，然后： - 将能够触发执行的工作区配置视为敏感内容 - 当代理创建或修改宿主机端自动化时，要求明确批准 - 在可能的情况下，让辅助程序的执行遵循与直接代理执行相同的策略 - 限制自动发现执行工作区控制的二进制文件 - 在调用和副作用级别对命令策略进行建模 - 除非明确需要，否则限制对特权本地守护进程的访问 - 保留用户创建、仓库创建和代理创建的文件之间的来源信息 - 监控信任交接点，而不仅仅是代理进程 必须理解的是，代理式开发是一种新的终端行为，而不仅仅是一个更好或更新的 IDE。 我们的**沙箱逃逸周**讲述的是一个新型软件打破既有假设的故事——将代理沙箱化是不够的。我们需要更好地理解非确定性、代理式软件的威胁模型，并对其进行妥善保护。 开发者终端已经足够复杂。代理增加了新的行为体，它们读取不受信任的内容，编写看似合理的文件，并在同一个环境中触发自动化，而这个环境里还保存着代码、凭证、基础设施访问权限和发布路径。 这项研究强调，对于代理而言，开发者在编码工具中所期望的沙箱边界——将代理限制在沙箱内、用户位于沙箱外——已经崩溃了。我们不断发现的边界既更加混乱又具有渗透性，因为***如果一个代理能够编写系统未来的输入，那么它从一开始就没有被沙箱化。*** **这就是为什么代理式安全需要自己的威胁模型。** 将代理的非确定性与现代 IT 环境的复杂性结合起来，未来还会有成千上万个这样的问题。业界正在边学边做，这也是为什么分享我们的发现、帮助企业在快速部署代理式系统时识别并降低风险如此重要。