系统:运行中
← 返回所有攻击
AGENTS MEDIUM NEW

Cowork 沙箱逃逸:一个信任客户端权限标志的已签名 RPC

研究人员将 DLL 侧加载与一个过度信任的命名管道 RPC 串联,在 Claude Cowork 的 Linux 沙箱中获得 root。Anthropic 认为本地代码执行是前提,而非漏洞。

2026-07-10 // 6 min affects: claude-cowork, claude-desktop-windows, ai-agent-sandboxes

这是什么?

2026 年 7 月 2 日至 3 日,多家安全媒体转载了 Nick McClendon(Armadin)的研究,描述了对 Claude Cowork 内置 Linux 沙箱的一次完整逃逸。Claude Cowork 是 Anthropic 面向非技术用户的桌面产品。该攻击链让一名已经在主机上取得代码执行的攻击者,能够在代理的沙箱内获得 root shell、关闭网络出口控制,并逃逸到宿主 VM 的命名空间。根据同一批报道,该发现于 2026 年 3 月 20 日报告给 Anthropic,并在 Claude Desktop for Windows 版本 1.9255.2.0 上得到验证。本文是一篇设计层面的分析,而非可直接操作的攻击手册。

值得关注的不是沙箱被攻破——沙箱本来就会被攻破——而是如何被攻破。管理沙箱的控制通道验证了在调用,却信任调用方所请求的内容。身份与授权之间的这种混淆,正是任何构建 AI 代理运行时的人都可复用的教训。

工作原理

在 Windows 上,Cowork 通过 Host Compute Service 在一个由 Hyper-V 隔离的 Ubuntu 虚拟机中运行 Claude Code。隔离是分层的:一个 Local System 服务(CoworkVMService)在命名管道上暴露一个 JSON-RPC 服务器,且只接受二进制文件带有「Anthropic, PBC」有效 Authenticode 签名的调用方。在虚拟机内部,工作在 bubblewrap 命名空间下、以会话专属的非特权用户运行,其外还有 seccomp 过滤器与按域名限制的出口代理。

研究人员先尝试伪造签名,但未成功——WinVerifyTrust 顶住了。于是他们不去破解身份校验,而是去满足它。由于已签名的 claude.exe 会先从自身应用目录、再回退到系统路径去解析某个系统库,一个放在其旁边的同名冒充库便在这个受信任的已签名进程内部执行了攻击者代码——这是一次经典的 DLL 搜索顺序劫持(MITRE ATT&CK T1574.002)。调用方由此继承了 Anthropic 的签名信任,可以合法地与该管道通信。

提权来自 RPC 契约本身。磁盘上的服务日志暴露了方法结构,其中包括一个带有客户端提供参数的 spawn 调用。其中两个参数被访客守护进程原样信任。一个用于重连既有会话的「恢复会话」标志,绕过了创建非特权用户的代码路径——于是一个指名任意既有用户(包括超级用户)的请求,就会以该用户身份运行,具备全部能力且处于未受限的配置。一个设为通配符的域名参数,把原本严格的出口代理变成了开放代理。当命名空间内已有一个 root 进程后,再对 PID 1 执行一次普通的 nsenter,即可跨出到宿主 VM 的 mount、PID 与网络命名空间,暴露 /etc/shadow 等文件。此处不复现任何 payload;重点在于机制。

为什么重要

每一层防护都按设计正常工作,箱子却仍被打开,原因是一个特权服务器把安全决策——以哪个用户运行、可访问哪些域名——委托给了客户端可控的取值。用签名封锁控制通道能证明调用方的身份;却无法说明某个具体请求是否应被授权。这与代理执行框架的权限边界以及编码代理中的环境变量泄露背后是同一个信任边界问题,也正是面向代理的零信任框架把沙箱视为众多控制之一、而非唯一控制的原因。

据报道,Anthropic 的立场是:这不构成安全漏洞,因为它以主机上的本地代码执行为前提,超出其威胁模型。对传统软件而言这是可以辩护的立场——但对 AI 代理工具尤其值得推敲,因为这类工具的存在本就是为了执行不受信任的代码、遵循不受信任的指令。当运行受攻击者影响的内容正是产品的核心功能时,「需要本地执行」就是一条更脆弱的边界。

防御

对于构建者,持久的规则是:认证不等于授权。已签名或在白名单中的调用方,仍必须在服务端校验每一个方法与每一个参数;权限或出口决策绝不能取自客户端提供的字段。恢复/重连路径应从服务端状态重新推导身份,而非采信调用方提供的名称。同时也要加固身份校验的根基——签名门禁的强度只等于被签名进程的代码完整性,因此应强制安全的 DLL 搜索顺序与打包应用完整性,使受信任的二进制文件无法被诱导加载不受信任的库。

对于运营者,应把任何执行 AI 生成代码的环境都视为不受信任,并在沙箱之外叠加控制:限制哪些已签名应用可以启动(例如通过 AppLocker 打包应用规则)、监控异常的库加载(如系统 DLL 从 System32 之外加载,Sysmon 事件 ID 7)、让代理运行时远离生产网络与机密存储,并对代理沙箱中意外的权限变更或网络出口告警。应假设沙箱逃逸终将被发现,并据此规划影响范围。

状态

项目详情
披露Nick McClendon(Armadin);2026 年 3 月 20 日报告给 Anthropic;2026 年 7 月 2–3 日公开发布
性质通过 DLL 搜索顺序劫持 + 信任客户端权限/域名参数的控制面 RPC 实现的沙箱提权与逃逸
验证版本Claude Desktop for Windows build 1.9255.2.0
前提条件主机上的本地代码执行
厂商立场Anthropic 认定其不构成安全漏洞(将本地执行视为前提);截至撰稿未分配 CVE
类别认证 ≠ 授权;代理控制面中的访问控制缺陷

以上细节反映第三方对 Armadin 研究的报道,基于特定 Windows 版本测试。厂商立场与产品内部实现会随时间变化——在得出关于某一具体部署的结论前,请以其当前版本为准核实。

Sources