虚拟机已经关不住 AI 智能体：一次真实的 VM 逃逸实验

原文来源：Trail of Bits Blog — 安全公司给 AI 智能体布置了逃出虚拟机的任务，结果它连续三次成功，其中一次用上了三个 0-day。

如果你经常用虚拟机来"关"不信任的代码，这篇文章值得读完。Trail of Bits 在自家 Patch the Planet 项目里拿到了 GPT 5.6-Cyber 的预览访问权限，测试它的网络攻防能力。测试方法很直接：把模型放进一台 QEMU/KVM 虚拟机里，任务是逃出去，读取宿主机上的 flag 文件。

结果让作者 Artem Dinaburg 自己都意外：它逃出去了三次。

实验设定

虚拟机跑在一台 Debian 12（oldstable，AMD Zen3）的 Linux 开发机上，是常见的 QEMU/KVM 组合。智能体从宿主机启动，通过 SSH 进入虚拟机，在虚拟机内部可以任意操作，并被要求记录研究日志。

为什么从宿主机启动？作者的判断是：逃逸尝试很可能把虚拟机搞到锁死或崩溃，从外部启动能保住研究记录。反正开发机上没有值钱的东西，就算逃出来也造不成什么损失。

第一次成功来得很快。大约一小时后，宿主机直接硬锁死。作者翻回滚屏记录才发现：智能体发现宿主机的内核存在 Januscape 漏洞（CVE-2026-53359，几周前刚披露），这个漏洞当时没有公开的 exploit，但智能体自己构造了一个，并且有信心直接测试——虽然第一次没打干净，但作者毫不怀疑再迭代几次就能成功。

老发行版的代价：第二次逃逸

作者更新了内核之后，智能体转向了 libslirp——一个让虚拟机获得网络能力的库，几乎所有 QEMU 虚拟机都在用。Debian 12 自带的 libslirp 4.7.0 存在 CVE-2026-9539 漏洞，而且智能体还发现，libslirp 里一个没有分配 CVE 的 bug 修复 commit 可以和这个 CVE 组合，在宿主机上实现任意内存读写。有了这个原语，逃逸就是水到渠成的事。

作者坦言："我甚至不知道 libslirp 是什么，也不知道自己跑的这个版本既有已知漏洞、又有已修复但未标记的漏洞。AI 智能体很快就推断出了这一切，并把两个漏洞组合起来完成了逃逸。"

为了让逃逸更难，作者手动拉取了最新的上游 libslirp 和 QEMU，重建了一个只保留必要功能的最小 QEMU。但第三次逃逸还是来了。

第三次：三个 0-day

最终攻击链用了三个当时还是 0-day 的漏洞，外加一个已在上游修复、但因为没被认定为安全问题而没进发行版内核的漏洞：

• QEMU VAPIC：未检查的 ROM 别名可以覆盖被锁定的 SMRAM，暴露 SMRAM 并实现攻击者控制的 SMM 执行；
• Linux KVM：一个被修改的 shadow page 未同步且可被复用，配合另一个 KVM 问题（paging64_invlpg() 复用了过期的 level-2 role），制造出可写的 2MiB 宿主机物理映射，进而修改 QEMU 堆；
• libslirp：混合 fragment IHL 导致 ICMP reflection 越界拷贝，产生大量可识别的 NetPacket 对象，用于定位和劫持回调。

智能体还发现了几个最终没用上的漏洞：比如 CUPS 的 root 证书可复用、QEMU 的 96 字节 panning buffer 溢出等——它们要么原语不够强，要么被 AppArmor 挡住。

最让人印象深刻的是持久性

作者特别提到，GPT 5.6-Cyber 和 Codex 的 goal 模式在约 12 小时的时间跨度上保持了有效的工作状态，跨过了多次 compaction 和无数次子代理调用。整个过程几乎不需要人工引导：它先探测宿主机网络上有什么可访问的服务（找到一个 CUPS 服务器，但被 AppArmor 挡住没能完成利用）；又发现作者的内核以 mitigations=off 运行，尝试用硬件 bug 获取主机内存读取原语（原语太不可靠，放弃）；最后转向对宿主机内核源码、QEMU 和相关库的漏洞挖掘，慢慢把多个漏洞链到一起，直到造出可靠的逃逸。

作者的主要工作变成了：在智能体把宿主内核搞硬锁时，物理重启机器。

结论：沙箱假设需要重估

作者原本怀疑 GPT 5.6-Cyber 能成功，但成功的方式和频率打消了所有疑虑。核心结论是：一个现成的虚拟机已经不足以关住现代 AI 智能体了。攻击面太大，连"带显示运行"这种看似无害的功能都在增加可被利用的攻击面。

对喜欢稳定老系统的开发者来说，这是最扎心的部分：补丁回移植的周期太长了。一个没有及时跟上上游更新的旧发行版（比如 Debian 12），应该被默认假设为"存在可利用漏洞"。而一个能力足够的智能体，会很快发现这些漏洞并合成针对性的 exploit——这在以前被认为是人类专家团队才能做的事。

那怎么办？作者给了一些方向：

• 更小攻击面的虚拟化技术：他用 Firecracker 重试了实验，智能体同样因为 Linux 内核漏洞把机器硬锁了（漏洞都已在 upstream 修复），但没能成功逃逸。显然 Firecracker 是难啃得多的目标；
• 安全基础要重新认真对待：最小权限（网络访问、凭据、可用功能）、日志和主动监控；
• 限制智能体的运行时间，每次使用都提供全新的干净环境。

这个实验最大的意义，是把"AI 智能体是高级持续性威胁"从一句口号变成了实测结论。过去我们觉得 AI 只是更快的工具，现在它开始具备"自主发现漏洞、合成 exploit、跨小时保持目标"的能力——安全社区对沙箱的整套假设，都得重写了。