BUG: Windows taskkill current-directory lookup may turn workspace-write job termination into host execution

[mxym]

先说结论：Windows 下，当前后台任务终止路径会由 Harness 宿主进程直接执行裸命令名 taskkill。Node/libuv 在 Windows 对这种裸 executable 的查找会先检查进程当前工作目录，再检查 PATH。而默认配置里，进程当前工作目录同时也是初始 session 的 workspace。

因此，一个只拥有 workspace-write 的模型如果在 workspace 中放入 taskkill.exe，随后启动并终止一个 background PowerShell job，宿主侧清理逻辑可能优先执行 workspace 中的 taskkill.exe，而不是系统的 System32\\taskkill.exe。

关键点是：这个 taskkill.exe 不是由受限 PowerShell token 启动的。它是 dsh-subprocess-local 的宿主 Node 进程为了清理 job 而调用 spawnSync() 启动，所以一旦搜索顺序被 workspace 文件劫持，代码会以 Harness 宿主用户的正常权限运行，绕过当前 workspace-write restricted-token 边界。

可能影响包括：

• 从 Windows workspace-write 直接进入 Harness 宿主用户权限下的代码执行；
• 写入当前 Agent workspace 之外、宿主用户可写的文件；
• 读取或修改宿主用户权限可访问、但 restricted token 本应阻止模型修改的状态；
• 后续对配置、脚本或其他宿主状态形成持久化或横向影响。

下面的分析基于当前 master：

47f943859bef60e4160492346772ded9b24f765a

我当前的测试环境不是 Windows，所以没有把下面的 Windows 端到端 marker PoC 冒充成已经动态跑过的结果；但涉及的 DSH 调用链和 Node/libuv Windows executable search 规则都是当前源码中的确定行为。

1. Windows 默认 composition 暴露 background PowerShell + jobs

基础 composition 在 Windows 下启用：

@deepseek-ai/dsh-subprocess-local
@deepseek-ai/dsh-sandbox-local
@deepseek-ai/dsh-sandbox-policy
@deepseek-ai/dsh-pwsh-sandbox
@deepseek-ai/dsh-tool-pwsh
@deepseek-ai/dsh-tool-jobs

对应位置：

packages/bundle/base/cordis.patch.yml

默认 sandbox mode 是：

mode: !!js process.env.DSH_PERMISSION_MODE ?? 'workspace-write'
workspaceRoot: !!js process.cwd()

tool-pwsh 默认开启 run_in_background：

enableRunInBackground: z.boolean().default(true)

因此模型正常就可以：

pwsh(..., run_in_background: true)
        ↓
得到 job id
        ↓
job_kill(job_id)

这不是额外插件或非默认 trusted extension 才有的能力。

2. 默认 session cwd 也是 Host 的 process.cwd()

Host API proxy 的默认 cwd 来自：

cwd: process.cwd()

创建 session 时，如果没有显式 workspace/cwd override：

const cwd = workspace?.path ?? request.payload.cwd ?? defaults.cwd

因此默认启动场景下：

Host process cwd
    == default session cwd
    == default workspaceRoot

也就是说，workspace-write 允许模型修改的初始 workspace 正好也是后续裸 executable 查找会检查的 Host current directory。

3. Windows workspace-write 明确允许模型在 workspace 内创建文件

Windows shipped sandbox 使用 restricted token + workspace SID 来约束写入。

项目自己的 Windows sandbox 文档明确描述：

workspace-write
    -> workspace + private temp 可写
    -> workspace 外普通 ACL-addressable write 被 restricted token 拒绝

同时 workspace-write 下 PowerShell 保持 FullLanguage（没有额外 host-wide WDAC/AppLocker 时），所以模型有正常的 workspace 内代码/文件生成能力。

攻击者不需要先获得任何 workspace 外写权限。

4. background job 的 job_kill 最终进入 subprocess tree termination

tool-pwsh 的 background producer：

const proc = ctx.shell.start(ctx.shell.resolve(request))

return {
  cancel: () => void proc.kill(),
  ...
}

jobs-local 的 kill()：

job.cancel(reason)

所以模型调用：

job_kill

会进入：

jobs-local.kill()
    ↓
producer cancel()
    ↓
ShellProcess.kill()
    ↓
SubprocessHandle.terminate()

5. Windows terminate 路径由宿主直接执行裸 taskkill

当前：

packages/subprocess/subprocess-local/src/spawn.ts

包含：

export function taskkillProcessTree(pid: number): void {
  if (pid <= 0) return
  spawnSync('taskkill', ['/PID', String(pid), '/T', '/F'], { stdio: 'ignore' })
}

并且 Windows tree signaling 直接调用它：

if (platform === 'win32') {
  taskkill(pid)
  return
}

这里没有：

%SystemRoot%\\System32\\taskkill.exe

这样的绝对系统路径，也没有为这个宿主 helper 设置一个可信 cwd。

这个 spawnSync() 发生在 Harness 宿主 Node 进程中，不是在前面启动的 restricted-token child 内。

所以它不受当前 pwsh 的 workspace-write token 限制。

6. Node/libuv 在 Windows 会先从 current directory 查裸 executable

当前 Node 24 使用 libuv 的 Windows process implementation 来解析裸命令名。

libuv 当前 src/win/process.c 的 search_path() 明确实现了 Windows executable 查找，并在 PATH 之前检查 current directory；对于没有扩展名的命令，还会尝试 .com 和 .exe。

参考源码：

https://github.com/libuv/libuv/blob/v1.52.1/src/win/process.c

因此：

spawnSync('taskkill', ...)

在 Windows 上并不等同于：

execute %SystemRoot%\\System32\\taskkill.exe

而更接近：

1. current working directory\\taskkill.com
2. current working directory\\taskkill.exe
3. PATH entries...

这正好与默认 model-writable workspace / process cwd 重合。

7. 完整利用链

把上面的当前实现串起来：

默认 Windows session
        ↓
workspaceRoot = Host process.cwd()
        ↓
model has workspace-write
        ↓
在 workspace 创建 taskkill.exe
        ↓
启动 pwsh background job
        ↓
模型调用 job_kill
        ↓
jobs-local -> ShellProcess.kill()
        ↓
subprocess-local terminate()
        ↓
Host Node process:
spawnSync("taskkill", ["/PID", ..., "/T", "/F"])
        ↓
libuv Windows search checks current directory first
        ↓
workspace\\taskkill.exe is selected
        ↓
attacker-controlled executable runs as unrestricted Harness host user

这里发生了明确的 authority transition：

restricted workspace-write model process
        ↓
只需要写当前 workspace
        ↓
trusted Host cleanup helper performs executable lookup
        ↓
unrestricted host-token execution

8. 为什么这不是 Windows sandbox 已声明的 partial-enforcement 限制

Windows ACL backend 的文档已经明确列出一些结构性 partial boundaries，例如：

• Everyone-granted external objects；
• NTFS hard-link aliases；
• FAT-class targets；
• read/network/process visibility 不受这套 write sandbox 约束。

这个问题不依赖这些条件。

攻击者只在 sandbox 明确允许的 workspace 内创建文件。

真正的问题发生在 sandbox 之外的宿主清理路径：Host 使用 model-writable current directory 去解析一个需要被当作 trusted OS helper 的裸 executable name。

因此它不是 restricted-token backend 报告 partial 所覆盖的“某些文件对象仍然可写”，而是一个独立的 untrusted executable search path / confused-deputy 问题。

9. 建议的无害 Windows 回归验证

可以在独立测试 workspace + 独立 outside marker directory 中验证，不需要修改真实系统文件。

测试结构建议：

workspace/
  taskkill.exe          <- harmless marker executable

outside-marker/
  marker.txt            <- initially absent

其中 taskkill.exe 只做：

write "HOST_EXECUTED" to outside-marker/marker.txt
exit

验证顺序：

1. session 使用默认 workspace-write

2. 先证明 restricted pwsh 直接写 outside-marker/marker.txt 被拒绝

3. 在 workspace 中放 harmless taskkill.exe

4. 启动一个长时间 background pwsh job

5. 调用 job_kill

6. 检查 outside-marker/marker.txt

如果 marker 出现，就同时证明：

restricted child direct outside write = denied
Host cleanup helper execution         = outside write succeeds

这能把 authority transition 明确区分出来。

10. 修复建议

这里不应该依赖 PATH/search-path 去定位系统 tree-kill helper。

Windows 下应把 helper 固定到可信系统路径，例如基于 %SystemRoot% / Windows system directory API 构造：

<System32>\\taskkill.exe

然后使用该绝对路径执行。

更稳妥的方案是完全避免外部 taskkill.exe，直接通过受控 Win32 API / Job Object 实现 tree termination；这样既消除 executable lookup，也减少外部 helper 行为和环境依赖。

建议增加 regression test，至少固定：

Host current directory contains attacker-controlled taskkill.exe
        ↓
tree termination
        ↓
attacker-controlled helper must never execute

并测试 Windows cleanup 路径实际调用的是绝对可信系统 helper（如果仍保留 taskkill 实现）。

总结

当前 Windows 默认能力和调用链为：

workspace-write grants workspace file creation
run_in_background is enabled by default
default session cwd = Host process.cwd()
job_kill reaches subprocess terminate
Windows terminate uses spawnSync("taskkill", ...)
libuv searches current directory before PATH

因此，model-writable workspace 可以进入一个本应只解析可信系统 binary 的宿主 executable-search boundary。

建议将 Windows tree termination helper 改为绝对可信路径，或者直接使用 Win32-native tree ownership/termination primitive，避免任何 current-directory / PATH executable resolution。

[mxym]

补充一个同根因、而且比正文的 run_in_background -> job_kill 更短的触发路径：前台 PowerShell 的正常 timeout/cancellation 也会进入同一个宿主 taskkill lookup。

当前：

packages/shell/pwsh-local/src/index.ts

前台 run() 使用：

using d = deadline(spec.signal, spec.timeoutMs, 'BASH_TIMEOUT')
const handle = this.ctx.subprocess.spawn(
  this.spawnSpec(spec, spec.stdoutMaxBytes, d.signal, argv),
)

而 spawnSubprocess() 会监听这个 signal：

const onAbort = (): void => { terminate() }
spec.signal?.addEventListener('abort', onAbort, { once: true })

Windows 下 terminate() 最终仍然调用：

spawnSync('taskkill', ['/PID', String(pid), '/T', '/F'], { stdio: 'ignore' })

所以不需要 jobs：

workspace-write Agent
    ↓
在默认 workspace / Host cwd 中放入 taskkill.exe
    ↓
调用普通前台 pwsh，并设置一个会命中的 timeoutMs
    ↓
PwshLocalExecutor deadline aborts
    ↓
SubprocessHandle.terminate()
    ↓
Host spawnSync("taskkill", ...)
    ↓
Windows current-directory executable search
    ↓
workspace\taskkill.exe 由 unrestricted Harness host token 执行

同样，用户/上游取消导致 spec.signal abort 时也会进入这条路径；subprocess/service teardown 也复用 tree termination。因此 job_kill 只是一个显式触发器，不是漏洞成立所必需的前提。

这进一步说明修复应位于共享的 Windows tree-termination boundary：把 taskkill 固定为可信绝对系统路径，或直接改用 Win32-native process-tree ownership/termination，而不是只在 tool-jobs 层规避。

[mxym]

补充一个Linux 上相同 Host-helper authority boundary 的变体。这不是 taskkill 搜索规则本身的延续，触发根因不同，因此我不另外开 Discussion；但最终 authority transition 和本帖相同：项目可控输入影响了未沙箱化 Host 原生 helper 的代码加载。

当前产品启动器会读取调用目录的 .env，并将通过 bootstrap 检查的普通变量物化到 Host process.env：

<project>/.env
    ↓
loadLayeredEnv()
    ↓
process.env

项目自己的配置边界文档明确规定，项目 .env 的信任“不包括改变 Harness 自身”，尤其不能决定“runtime 在被要求执行的程序之前还会执行什么代码”。当前 deny set 已覆盖 LD_PRELOAD、NODE_OPTIONS、BASH_ENV、各语言 startup hook、DYLD_* 等，但没有覆盖 Linux GUI/runtime 的动态模块变量，例如：

GIO_EXTRA_MODULES
GTK_PATH
GTK_MODULES
QT_PLUGIN_PATH
QT_QPA_PLATFORM_PLUGIN_PATH

同时：

packages/util/native-command/src/index.ts

中的 Host native runner 使用：

execFile(command, args, {
  encoding: 'utf8',
  signal,
  windowsHide: true,
})

没有提供独立 env，因此原生 helper 会继承完整 Host process.env。

Linux host.openPath 最终调用：

xdg-open <path>

而 GNOME/GNOME3（以及部分 MATE/XFCE 路径）的 xdg-open 会进入：

gio open <path>

GIO 会从 GIO_EXTRA_MODULES 指定的目录加载动态模块。

我在当前提交上做了无害动态验证。测试项目只有：

GIO_EXTRA_MODULES=./modules

./modules 中是一个测试 .so，constructor 只向项目外的独立临时 marker 写一行文本，不读取任何真实用户数据。

测试按真实产品调用顺序：

process cwd = test project
        ↓
loadLayeredEnv("dsh", project)
        ↓
GIO_EXTRA_MODULES = ./modules 被接受并进入 Host process.env
        ↓
runNativeCommand("xdg-open", ["test.txt"])
        ↓
GNOME xdg-open -> gio open
        ↓
GIO 加载 ./modules 中测试模块
        ↓
Host marker 被写入

当前源码测试输出：

ENV_NATIVE_RELATIVE_PROOF {
  "env": "./modules",
  "marker": true,
  "content": "HOST_GIO_EXEC\n"
}

Test Files  1 passed (1)
Tests       1 passed (1)

另外直接对系统 GIO 做了控制实验：设置相同 GIO_EXTRA_MODULES 后运行 gio，测试模块也会立即被加载。xdg-open 最终因为测试环境没有给该文本文件注册桌面应用而返回失败，但模块 constructor 已经在这个失败之前执行，因此后续应用能否真正打开不影响代码加载 primitive。

这条路径和正文 Windows taskkill 的共同点是：

项目/受限世界可控状态
        ↓
进入 trusted Host native-helper boundary
        ↓
helper 在未沙箱化 Host 权限下加载/执行攻击者代码

区别是这里不依赖 Windows executable search，也不是运行中 Agent 写 taskkill.exe；它需要用户从携带该 .env 的项目启动 DSH，并在 Linux 桌面环境触发原生打开路径操作。

修复上，我觉得应该同时考虑两层：

1. 把能改变原生/runtime 模块加载的变量归入 loadLayeredEnv 的 bootstrap-only policy（至少覆盖实际支持的 GUI/runtime loader family）；
2. defense-in-depth：Host native integration helper 不要直接继承项目 materialized 的完整环境，而使用一份适合 OS integration 的明确环境基线。

项目现有设计文档自己已经指出“逐变量枚举是一场输的游戏”，所以第二层尤其有价值：否则新增一个 Host helper/runtime 后，还需要重新猜一遍它有哪些 module/plugin loader 环境变量。