[Security] 安全审计报告：沙箱/审批边界绕过与本地 RPC 无认证（PoC 可私下提供）

[HGCCPU]

安全审计报告：沙箱/审批边界绕过与本地 RPC 无认证

English abstract: Security audit of deepseek-harness 0.1.0-rc.5 (47f9438). Beyond the four issues publicly disclosed today (2026-08-14) elsewhere, we independently verified seven additional findings: two High (unauthenticated local/LAN RPC surface, plus the unpinned host-filesystem primitives it carries) and five Medium (workflow tool bypasses the sandbox modes, escalation approval is not bound to the command, host-only dynamic packages run with zero approval, the sandbox ctx facade forwards capability services, Landlock reports full enforcement on filesystems it cannot govern). Full PoCs exist and can be shared privately — see the end of this post.

---

审计范围

• 对象：deepseek-ai/deepseek-harness @ 0.1.0-rc.5，commit 47f9438（2026-08-14 克隆）
• 威胁模型：① 同机/LAN 恶意进程攻击 HTTP RPC 面；② 模型被 prompt injection 诱导；③ "只读沙箱"部署承诺的完整性

发现摘要（每条含代码位置；完整 PoC 见文末交付说明）

High

H1 · 本地 RPC 无认证 — /api 信任篱笆只防浏览器（DNS rebinding/CSRF），非认证层（packages/client/connection/src/api-request-trust.ts）。同机任意进程伪造 Host: 127.0.0.1 即可创建 danger-full-access（approval: never）会话，无审批执行命令、读全部会话。代码注释已自认该边界。

H2 · --host 0.0.0.0 = 局域网无认证控制 — 绑定全接口时 CLI 自动把本机 LAN IP 加入 trustedHosts（packages/bundle/web-app/src/index.ts），LAN 内任意主机获得与 H1 相同能力。建议：Jupyter 式随机 token；0.0.0.0 时强制 --auth-token。

H1/H2 放大点 · 无认证 RPC 面携带宿主文件系统原语 — session.create 接受任意 cwd 字符串（即沙箱写根，packages/host/apiproxy/src/api/sessions.schema.ts），无"该目录是用户挑选的 workspace"校验；且 host.listDirectory（任意路径浏览）、host.createDirectory（任意父目录建目录）、workspace.create（任意路径收编为 workspace）不在 PRIVILEGED_METHODS 的 loopback pin 列表内（packages/client/connection/src/index.ts）。攻击者可将沙箱写根指到 ~/.ssh 等敏感目录后驱动 agent 写入。

Medium

M1 · workflow 工具绕过沙箱模式 — workflow 工具无沙箱策略门（packages/workflow/tool-workflow/src/index.ts），脚本经 vm.createContext({}) + 冻结的宿主 realm 闭包执行（packages/workflow/workflow-worker-thread/src/runtime.ts:90-111）。冻结不隐藏 .constructor：一行脚本即可取得宿主 process 并写任意宿主文件——不经过 bwrap/Landlock/Seatbelt 任何一层，read-only 模式的"拒绝写入"承诺被完全绕过。

M2 · 沙箱提权审批不绑定命令 — approveEscalation 的审批载荷只含 {agent, toolName, callId, reason}（packages/sandbox/sandbox/src/escalation.ts），执行侧批准后直接跑 args.command、无比对（packages/shell/tool-bash/src/index.ts:330-347）。"重试同一条被拒命令"仅为 prompt 级约束。

M3 · host-only 动态包零审批 — 审批门只在 clientCode !== undefined 时武装（packages/extensions/cordis-host-runner/src/index.ts:270-290）；纯 host 半边（跑在宿主进程的半边）直接激活，全程无审批事件。

M4 · 沙箱 ctx 外观放行能力服务 — 注入服务无白名单，代理只拒绝返回 Context 的方法（packages/extensions/cordis-host-runner/src/guard.ts:685-697）；inject: ['subprocess'] + spawn() 返回的进程句柄直接穿过。M3+M4 组合 = 零审批、无沙箱的宿主进程执行链。

M5 · Landlock 对 NFS/CIFS/FUSE 无效却报告 full — 探测只测内核 ABI（native/landlock-run），不检查 workspace 文件系统类型（packages/sandbox/sandbox-local/src/index.ts:177-187）；网络文件系统上的写入不受 Landlock 约束，违反 full 的文档定义。

L1 · Landlock workspace-write 授予宿主共享 /tmp（packages/sandbox/sandbox-local/src/profiles.ts）；L2 · Code Mode 进程内执行（已文档化，建议 UI 明示）。

与今日已公开研究的边界

今天公开的四个漏洞（!!js 配置求值、read-only 全盘读、动态插件 vm 的 exec 泄漏、exec→subprocess 链）不在本报告的独立发现之列；本报告的 H1/H2、M1–M5 是独立路径（M1–M4 各有独立 PoC）。

PoC 交付与请求

• 三个 PoC 已编写并在本仓库真实代码路径上验证通过（vitest 两个 + 独立 node 脚本一个）。
• 本仓库未开启 private vulnerability reporting（API 返回 403），且无 SECURITY.md。请求维护者：开启 GitHub private vulnerability reporting，或提供安全邮箱，我们随后将完整 PoC 与利用细节私密送达。

[Electricitysheep]

这份审计很有价值，尤其是"workflow 工具绕过沙箱模式"和"审批未绑定到具体命令"这两条——它们点破了"沙箱存在 = 安全"的误区，正是选型时最容易被忽略的边界。

我们在维护的 dsh 中文手册里，第 8 章（工具与上下文/安全模型）和第 12 章（已知不足）记录了部分已知边界，正在写的第 13 章（安全与沙箱模型）会把这类审计发现整理成"插件/生产部署安全基线"：
https://github.com/Electricitysheep/dsh-handbook

建议官方把这类 PoC 审计纳入 rc 阶段发布 checklist（当前 rc.5 → rc.6 迭代这么快，安全回归很容易漏）。如果愿意，这份审计的公开版可以收录进我们手册的安全章节作为社区案例（署名）。