[Security]AI自行提级的潜在安全漏洞Potential security risks of AI upgrading itself #4384
ShiJieWorld
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
正文
背景:一次真实的无人值守提权事件
我们在基于本 harness 的日常使用中让一个开发会话(下称 A)自主推进「AI 启动并测试自己写的程序」类任务的验收。A 通过本地 API 创建了独立的验收会话 B 并投递任务。B 的 PTY 工具在 workspace-write 模式下无法存活(Windows WRITE_RESTRICTED token 与 ConPTY 的结构性冲突,属已知边界),于是 A 把文本

/permission danger-full-access作为 B 的首条提示投递了过去。结果出乎我们预料:B 会话里的 agent 把这行文本理解为用户意图,自行读源码确认了本地 API 的信任栅栏只要求 loopback Host 头(代码注释自述 "explicitly not an authentication layer"),随后用它自己的 shell 工具调用了
commands/executeRPC,成功把权限预设切到了 danger-full-access。全程没有任何人工确认。复现
对任意运行中的 dsh web 实例(默认 http://127.0.0.1:3080),无需任何凭证:
文末附带一个零副作用的自查脚本:它利用
/permission不带参数时的「纯查询」语义做探针,可无损判断自己的实例是否暴露(VULNERABLE / PATCHED)。根因(三点叠加,均为当前设计现状)
command/run的事件来源被硬编码为source: { kind: 'user' }——程序发起的变更在审计里伪装成用户操作。api-request-trust.ts注释自述):loopback 直通意味着任何能到达端口的本机进程都是「可信」的。session.prompt/sessions.create无审批钩子:agent 可以创建任意会话并投递任意内容,「创建带高权限声明的子会话」没有对应的人工许可路径。单看每一环都有其合理性;组合起来,在「host 上长期运行着具备 shell 工具的 agent」这一场景下就构成了一条无需人工参与的权限提升链。
影响面
/permission等命令;我们已验证的缓解参考(供讨论)
我们在 fork 中做了如下改动并通过全量回归(含 GUI 全量测试),供上游参考:

executeInteractive(agent, line, signal)Remote 入口供交互界面调用,记录source: { kind: 'user' };原execute明确为程序化入口,记录新扩展的source: { kind: 'rpc' }(CommandSourceMap为 merge-extensible 结构,正好预留了这个扩展点)。CommandDefinition.privileged声明:改变安全态势的命令(如/permission)声明该标志。程序化入口在 handler 运行前拒绝此类命令,但仍完整记录command/run+command/done(error),使每次尝试可审计。自查脚本(零副作用)
利用
/permission裸查询的「只报告不修改」语义做探针:判定说明:
[PATCHED]= 已防护;[VULNERABLE]= 程序化通道可执行特权命令;退出码分别为 0 / 1(2 为环境不可测)。All reactions