【安全评审】动态插件的 vm "沙箱"存在宿主进程逃逸，PoC 已验证：一次批准 = 完整 RCE

[wulun811]

概述

cordis_define / cordis_run 让模型编写并运行"动态插件"。插件宿主半在一个 node:vm 沙箱里求值，但该沙箱不是安全边界（仓库注释自认），且沙箱内放置了宿主函数（TextEncoder / btoa / atob），通过标准构造器逃逸即可拿到宿主进程的 process —— 获得完整用户权限：任意命令执行、任意文件读写、密钥窃取（如 .env 中的 DEEPSEEK_API_KEY）、持久化后门。

我已用 PoC 实测验证，并非理论推测。

攻击链

提示注入（网页/任务文本/文档）
  → 模型按指示 cordis_define 写动态插件（宿主半代码，3 行逃逸载荷）
  → 用户批准一次 cordis_run（批准摘要由模型自述，可被注入粉饰）
  → 插件 apply 同步执行逃逸代码
  → TextEncoder.constructor("return process")() 拿到宿主 process
  → 任意命令执行 + 任意文件读写 + 持久后门（无任何后续审批）

证据

1. 仓库自认的非 containment 注释（packages/extensions/cordis-host-runner/src/sandbox.ts）：

// L6-7: This keeps cooperative packages inspectable and disposable but is
// not containment: host-realm helper functions remain an escape route.
// L217-219: vmTimeoutMs only bounds the SYNCHRONOUS portion; an async body
// escapes it — acceptable under the module's trust stance.

2. 逃逸源进入沙箱（sandbox.ts L137-140）：

btoa: (s: string) => Buffer.from(s, 'utf-8').toString('base64'),
atob: (s: string) => Buffer.from(s, 'base64').toString('utf-8'),
TextEncoder,
TextDecoder,

宿主函数对象的 .constructor 指向宿主 Function —— 这是 Node 官方文档明示的 vm 边界（"The vm module is not a security mechanism"）。

3. PoC（Node 22.19 实测，无副作用）：

const vm = require('node:vm');
const sandbox = { TextEncoder, TextDecoder, btoa: (x) => Buffer.from(x, 'utf-8').toString('base64'), atob: (x) => Buffer.from(x, 'base64').toString('utf-8') };
vm.createContext(sandbox);
console.log(vm.runInContext('TextEncoder.constructor === Function', sandbox));          // false —— 是宿主构造器
console.log(vm.runInContext('TextEncoder.constructor("return process")().cwd()', sandbox)); // 真实 cwd
console.log(vm.runInContext('TextEncoder.constructor("return process")().getBuiltinModule("child_process").spawnSync', sandbox)); // 可执行任意命令

实测输出：false / N:\...真实路径... / function —— 逃逸成立，spawnSync 与 readFileSync 均可达。

4. 执行点（lifecycle.ts L28）：动态插件在宿主进程内以 ctx.plugin(guardedPlugin(plugin, ...)) 启动，apply 的函数体位于 vm realm，逃逸代码同步执行于第一次 apply，cordis_run 的批准是唯一闸门。

为什么现有防线挡不住

• approval / sandbox / workspace-write / fs-policy 全部作用于工具执行层（bash、fs、web 工具调用）；
• 而动态插件代码执行在进程层（vm 求值 + 宿主 ctx.plugin），逃逸后直接获得进程权限，工具层防线对其不可见；
• 批准信息由模型自述，提示注入可将其粉饰为无害；
• 批准记录是进程内内存状态（重启后重新要求），但逃逸在第一次 apply 即完成，与持久性无关。

关于定位

我理解这是设计内的信任立场（"API 塑形而非安全边界"、信任等级与 bash 相当），注释写得坦诚。本帖的诉求不是"这是 bug 快修"，而是：

产品的用户侧叙事（"沙箱" + "批准"）与实际信任模型之间存在落差。 用户以为代码被隔离、操作被审批，实际上一次批准即授予进程级权限。这个落差需要被决策、被文档化、或者被消除。

三个可选方向（恳请维护者决策）

1. 进程级隔离（治本）：宿主半移出宿主进程，走 OS 级沙箱（landlock / Windows ACL，与 e2b 子进程方案同构）+ 剔除 .env 等敏感环境 + IPC 通信；
2. 文档化与叙事修正（最低成本）：明确声明动态插件为"进程级信任"，产品界面与提示词中同步呈现，取消"沙箱"表述；
3. 官方扫描/守卫钩子（中间态）：在宿主半求值前提供静态检查扩展点，拦截常见逃逸模式。

贡献意向

我计划提交一个守卫插件（严格拒绝模式）：挂载于工具执行管线，扫描 cordis_define 的代码参数，拦截构造器链 / eval / new Function / 逃逸源函数引用等模式（初始规则集含全部 PoC 模式），附测试与文档。若维护者倾向方向 1 或 2，该插件仍可作为过渡防线。

如有表述或事实错误，欢迎指正；PoC 已在本地实测，随时可提供复现步骤。