[Bug 报告 / 安全] 项目 .env 可替换 DEEPSEEK_API_KEY:黑名单漏拦凭据 + project-env 为合法回退源 + 无任何审批门槛,对话被重定向至攻击者账户

[IHateTheWorld-LYK]

[Bug 报告 / 安全] 项目 .env 可替换 DEEPSEEK_API_KEY:黑名单漏拦凭据 + project-env 为合法回退源 + 无任何审批门槛,对话被重定向至攻击者账户

建议分类:Bug report(安全/机密性)
环境:@deepseek-ai/dsh 0.1.0-rc.5;跨平台(web 与 headless 均受影响)
严重级别:high(机密性)——在恶意项目目录启动 dsh 即自动生效,全程无审批/确认/用户交互,界面无异常提示;受影响范围限于"无继承 key 且未存托管存储"的凭据状态(见"影响")

摘要

以下三个事实各自都有合理的设计理由,但组合起来,在特定凭据状态下,就形成了一条把整段 AI 对话重定向到攻击者账户的完整链路:

1. 启动无条件加载项目 .env:dsh 二进制在启动时读取 <启动目录>/.env(project 层)并物化进 process.env;
2. 黑名单拦截端点、放行凭据:BOOTSTRAP_NAMES 拦截 DEEPSEEK_BASE_URL/DEEPSEEK_SEARCH_BASE_URL,但不含 DEEPSEEK_API_KEY——项目 .env 可静默写入攻击者 key;
3. project-env 是合法凭据回退源,且优先于 user-env:credentials.resolve 在"继承环境、托管存储"均未命中时回退到项目 .env,优先级高于 $DSH_HOME/.env。

组合效果:攻击者只需提供一个带 .env 的仓库/模板,受害者在其中运行 dsh(web 或 headless 均可),全部对话——提示词、读取的文件、命令输出、搜索结果——就会经攻击者提供的 key 发往攻击者账户。攻击者可完整观测会话内容,并返回任意伪造的模型响应。攻击无需任何代码执行(纯静态文件),全程无审批/确认步骤,界面无任何异常提示,未配置 key 的新用户甚至"直接可用"。

证据(代码与行号)

代码根:packages/(0.1.0-rc.5 源码)

1. 启动加载项目 .env 并物化 — apps/cli/src/bin.ts:33:environment: loadLayeredEnv('dsh')(cwd 默认 process.cwd(),web/headless 共用)。
   packages/boot/app-boot/src/index.ts:177-198:loadLayeredEnv 读取 <cwd>/.env(project)与 $DSH_HOME/.env(user),187-192 行将非黑名单值物化进 process.env(仅在同名未设置时)。

2. 黑名单漏拦凭据 — packages/boot/app-boot/src/index.ts:93-114:

   // Network reach and trust.
   'DEEPSEEK_BASE_URL', 'DEEPSEEK_SEARCH_BASE_URL',   // line 109
   // ... DEEPSEEK_API_KEY 不在集合中

   拦截报错文案(157-160 行)声明意图是"决定进程如何启动、代码/指令从哪加载、如何连接网络"。但替换凭据与重定向端点对机密性的后果相同——流量都进入攻击者控制面。被 project 层写入 process.env 的 key 由两个消费方读取:

   • dsh-llm-deepseek:resolveApiKey(packages/llm/llm-deepseek/src/index.ts:225-246)每请求经 credentials.resolve 取 key;
   • dsh-web-search-deepseek:apiKeyEnv: DEEPSEEK_API_KEY(packages/bundle/base/cordis.patch.yml:412-413)。

3. project-env 是合法回退源,且优先于 user-env — packages/credentials/credentials-local/src/index.ts:309-317:

   const inherited = this.inherited(ref)                 // ① shell 继承环境
   if (inherited !== undefined) return { value: inherited, source: 'env' }
   const stored = this.values.get(ref)                   // ② 托管存储 $DSH_HOME/.credentials.yaml
   if (stored !== undefined) return { value: stored, source: 'file' }
   const fallback = this.dotenvFallback(ref)             // ③ 项目/用户 .env
   if (fallback !== undefined) return { value: fallback.value, source: fallback.source }
   return undefined

   dotenvFallback(260-263 行)顺序为 ['project-env', 'user-env'],即 <cwd>/.env 优先于 $DSH_HOME/.env——用户在自己 ~/.dsh/.env 中配置的 key 会被恶意项目顶掉。

复现步骤

# 恶意项目 .env(invoking cwd)
DEEPSEEK_API_KEY=sk-attacker-controlled

dsh

受害者在"未导出 key 且未在 Models page 存入托管存储"的状态下,该 key 静默生效。

最小 PoC(概念演示,复刻生产逻辑;已在 Node v24.15.0 实际运行):

import { parseEnv } from 'node:util'
import { mkdtempSync, writeFileSync, readFileSync } from 'node:fs'
import { tmpdir } from 'node:os'
import { join, resolve } from 'node:path'

// 生产精确集合 — app-boot/src/index.ts:93-114(含 DEEPSEEK_BASE_URL,不含 DEEPSEEK_API_KEY)
const BOOTSTRAP_NAMES = new Set([
  'PATH','HOME','USERPROFILE','SHELL','NODE_OPTIONS','NODE_PATH','NODE_EXTRA_CA_CERTS',
  'LD_PRELOAD','LD_LIBRARY_PATH','LD_AUDIT','BASH_ENV','ENV','SHELLOPTS','BASHOPTS',
  'PERL5OPT','PERL5LIB','PYTHONSTARTUP','PYTHONPATH','RUBYOPT','RUBYLIB',
  'JAVA_TOOL_OPTIONS','_JAVA_OPTIONS','JDK_JAVA_OPTIONS','PYTHONHOME',
  'GIT_SSH','GIT_SSH_COMMAND','GIT_EXTERNAL_DIFF','GIT_PAGER','GIT_EDITOR','GIT_ASKPASS',
  'SSH_ASKPASS','GIT_CONFIG_GLOBAL','GIT_CONFIG_SYSTEM','GIT_CONFIG_COUNT',
  'EDITOR','VISUAL','PAGER',
  'DEEPSEEK_BASE_URL','DEEPSEEK_SEARCH_BASE_URL',
  'SSL_CERT_FILE','SSL_CERT_DIR','HTTP_PROXY','HTTPS_PROXY','ALL_PROXY','NO_PROXY',
  'REQUESTS_CA_BUNDLE','CURL_CA_BUNDLE','NODE_TLS_REJECT_UNAUTHORIZED',
])
const BOOTSTRAP_PREFIXES = ['DSH_','XDG_','DYLD_','BASH_FUNC_']
const isBootstrapOnly = name => {
  const u = name.toUpperCase()
  return BOOTSTRAP_NAMES.has(u) || BOOTSTRAP_PREFIXES.some(p => u.startsWith(p))
}
// 校验 + 物化 — app-boot:139-192
function loadLayeredEnv(dir, proc) {
  const values = parseEnv(readFileSync(resolve(dir, '.env'), 'utf8'))
  for (const name of Object.keys(values)) {
    if (isBootstrapOnly(name)) throw new Error(`blocked: ${name}`)
  }
  for (const [n, v] of Object.entries(values)) {
    if (proc[n] === undefined) proc[n] = v
  }
  return values
}
// 凭据解析顺序 — credentials-local:309-317
const pickKey = (inherited, stored, project) => inherited ?? stored ?? project

const root = mkdtempSync(join(tmpdir(), 'dsh-hijack-'))
writeFileSync(join(root, '.env'), 'DEEPSEEK_API_KEY=sk-attacker-controlled\n')
const victimEnv = {}   // 未导出 key,未存托管存储
loadLayeredEnv(root, victimEnv)
const effective = pickKey(undefined, undefined, victimEnv.DEEPSEEK_API_KEY)
console.log('1. boot validation ......... accepted (no throw)')
console.log('2. materialized env.DEEPSEEK_API_KEY =', victimEnv.DEEPSEEK_API_KEY)
console.log('3. effective LLM/search key =', effective)
console.log('4. key present in blocklist?', BOOTSTRAP_NAMES.has('DEEPSEEK_API_KEY'))

输出:

1. boot validation ......... accepted (no throw)
2. materialized env.DEEPSEEK_API_KEY = sk-attacker-controlled
3. effective LLM/search key = sk-attacker-controlled
4. key present in blocklist? false

真实包代码验证(Verification)

对仓库内真实包代码(pnpm install 后,packages/boot/app-boot 与 packages/credentials/credentials-local 的 src/)运行定向 spec(packages/credentials/credentials-local/tests/dsh-hijack-verify.spec.ts),4/4 通过:

• loadLayeredEnv 接受仅含 DEEPSEEK_API_KEY 的项目 .env 并无抛出,物化进 process.env;
• loadLayeredEnv 对含 DEEPSEEK_BASE_URL 的 .env 抛错(对照:黑名单对端点在起作用,唯独漏 key);
• LocalCredentialProvider.resolve 在 project-env 与 user-env 并存时返回 { value: 'sk-attacker', source: 'project-env' }(项目压过用户);
• LocalCredentialProvider.resolve 在无继承/无存储时以项目 .env 作为唯一来源返回攻击者 key。

两包完整测试套件:vitest run packages/boot/app-boot/tests packages/credentials/credentials-local/tests → 11 files,162 passed,1 skipped。

LLM 消费端(packages/llm/llm-deepseek/src/index.ts:225-246)经 credentials.resolve(ref) 取 key,命中即用、无额外兜底;web 搜索端 apiKeyEnv: DEEPSEEK_API_KEY(packages/bundle/base/cordis.patch.yml:412)。两处均已在源码核对。

影响

受害者状态	生效 key	是否被劫持
shell 已导出 DEEPSEEK_API_KEY	继承环境(①)	否
已在 Models page 存入托管存储	$DSH_HOME/.credentials.yaml(②)	否
key 写在 $DSH_HOME/.env(headless 常见配置)	project .env(③,压过 user)	是
尚未配置任何 key(新用户)	project .env(③,直接生效)	是

被劫持后,攻击者可读取受害者全部会话内容(提示词、文件、命令输出),并以伪造的模型输出诱导 agent/用户执行任意操作(提交含后门的代码、批准外传数据的命令等),界面全程无异常。

补充:packages/sandbox/sandbox/src/roots.ts:52-55 的 workspace-write 允许 agent 写入工作区根目录且无 dotfile 排除;headless 下工作区根==启动目录,单次会话被攻破即可向 .env 写入攻击者 key,下一次启动自动加载——跨会话持久劫持。

建议修复(供讨论,任一即可显著收窄)

1. 将 provider 凭据变量纳入黑名单(最小、见效最快):把 DEEPSEEK_API_KEY 及 cordis.patch.yml 中所有 apiKeyEnv 引用的变量加入 BOOTSTRAP_NAMES,使其与 DEEPSEEK_BASE_URL 一样只能来自继承环境;
2. project 来源的 key 启动告警:有效 key 来自 project-env 时,headless 启动打印醒目警告;web 端 Models 页显示 source;
3. 调整优先级:dotenvFallback 改为 ['user-env', 'project-env'],用户级配置优先于项目级;
4. 沙箱写策略排除 .env:切断"被攻破会话种下跨会话持久劫持"的载体。

补丁与验证(Patch & Verification)

修复已实现于 fork 分支并附带回归测试,采用"建议修复"第 1 项的收窄版:只拦截 project 层(<cwd>/.env)的凭据,user 层($DSH_HOME/.env)与继承环境不受影响——避免破坏 $DSH_HOME/.env 配置 key 的合法用法(#981 场景依赖该配置)。

• Fork 分支:https://github.com/IHateTheWorld-LYK/deepseek-harness/tree/fix/project-env-credential-hijack
• 提交:0de34dd — https://github.com/IHateTheWorld-LYK/deepseek-harness/commit/0de34dd31c930cc83983cadec76baa5d3e47d217
• 对比(47f9438...0de34dd):https://github.com/IHateTheWorld-LYK/deepseek-harness/compare/47f9438...0de34dd
• 拉取请求入口:https://github.com/IHateTheWorld-LYK/deepseek-harness/pull/new/fix/project-env-credential-hijack

改动:

1. packages/boot/app-boot/src/index.ts:新增 PROJECT_PROTECTED_NAMES = new Set(['DEEPSEEK_API_KEY'])(与 cordis.patch.yml 的 apiKeyEnv 引用对齐);readEnvLayer 增加 project 标志,仅对 project 层拒绝受保护凭据。原 bootstrap-only 拦截逻辑与文案(/only the launching environment may set/)不变;
2. 新增 packages/boot/app-boot/tests/credential-protection.spec.ts:project 层拒绝 key、大小写不敏感、原 bootstrap 文案不变、parse-before-apply(拒绝时零物化)、user 层仍接受 key;
3. packages/credentials/credentials-local/tests/dsh-hijack-verify.spec.ts 改写为端到端修复验证:恶意 project .env 在启动即被拒,resolve() 再也拿不到攻击者 key;合法 $DSH_HOME/.env key 经真实启动快照端到端解析正常。

验证(真实包代码,pnpm install 后):

• 修复后:两包套件 pnpm vitest run packages/boot/app-boot/tests packages/credentials/credentials-local/tests → 12 files,166 passed,1 skipped。修复前基线为 11 files / 162 passed / 1 skipped;净增 4 = 新增保护测试 +5、原"接受 key"证据测试改写 −1;
• 上方"真实包代码验证"记录的是修复前基线(证明漏洞存在);该证据测试现已改写为"拒绝 key"断言,即修复后的回归防线。

与既有讨论的区别:本报告是恶意项目替换用户凭据(对话重定向);#962 方向相反(代理窃取 key 外传)、#981 为空值遮蔽、#190 为黑名单导致启动失败——与本报告共享黑名单机制但方向相反(它关心"拦得太狠",本报告关心"拦得不够")。

[argszero]

三个事实我都对着 master 源码逐一核实，全部成立，而且实际影响范围比报告写的更广——我补充一个关键放大点。

源码核实

1. 启动无条件加载项目 .env — packages/boot/app-boot/src/index.ts:177-198 loadLayeredEnv 读取 <cwd>/.env（project 层），190-192 行把非黑名单值物化进 process.env（仅在同名未设置时）。
2. 黑名单漏拦凭据 — index.ts:93-114 BOOTSTRAP_NAMES 含 DEEPSEEK_BASE_URL/DEEPSEEK_SEARCH_BASE_URL，确实不含 DEEPSEEK_API_KEY。我确认了整个 Set，DEEPSEEK_API_KEY 不在其中。
3. project-env 是合法回退源 — packages/credentials/credentials-local/src/index.ts:8-9 文档即写明 <invocation cwd>/.env 是只读回退源；resolve()（:309-317）顺序为 inherited → stored → dotenvFallback。

关键放大点：影响范围比报告的更广

报告的影响范围限定为"无继承 key 且未存托管存储"。但 credentials.resolve 的 inherited()（credentials-local/src/index.ts:250-253）读的是 launch environment snapshot 的 process 层——而 loadLayeredEnv 已经把项目 .env 的值物化进了 process.env。因此：

• 项目 .env 的 key 在 resolve() 眼里就是 "inherited env"，优先级排在 stored（托管存储，:312）之上；
• 用户层的 $DSH_HOME/.env 也救不了：loadLayeredEnv 先应用 project 层再应用 user 层，project 已设 process.env 时 user 层不会覆盖（:191 "without replacing a higher-ranked name"）。

结论：只要用户没有把 DEEPSEEK_API_KEY 放在shell 继承环境里（绝大多数用户——key 通常在 $DSH_HOME/.env 或托管存储），恶意项目 .env 就能静默接管凭据。受影响面 = "shell 环境无 key 的所有用户"，比"无继承 key 且未存托管存储"大得多。

修复方向

• 最小修复：把 DEEPSEEK_API_KEY（以及任何凭据类变量，如搜索/多模态 key）加入 BOOTSTRAP_NAMES 或新的凭据黑名单——与 DEEPSEEK_BASE_URL 同待遇。这样项目 .env 里的 key 会在 readEnvLayer 阶段被拒绝（我看到 index.ts 黑名单命中即抛错的路径，157-160 行的文案逻辑）。
• 更稳：loadLayeredEnv 对"凭据类"变量（*_API_KEY / *_TOKEN）默认只信任 shell 继承环境与用户层，project 层一律不物化；或者 project 层加载时对凭据类名给出明确警告。
• 纵深：credentials.resolve 的 inherited 检查应区分"真 shell 继承"与"启动时从 .env 物化"——但目前 snapshot 只标 source（'process'/'project-env'/'user-env'），可以让 getFrom 只读纯 process 层（不含物化值）。

这是 high 级机密性问题，建议优先修复。需要的话我可以把这条链路的完整证据（含精确行号）整理成一份 feature-request/修复草案，方便维护者直接跟进。