JavaLYG

Docker Sandboxes 沙箱逃逸 CVE-2026-77179:virtio-fs 符号链接机制与升级验收

2026 年 9 月 19 日,安全研究员公开了 Docker 在 macOS 上沙箱逃逸的完整细节:跑在 Docker Sandboxes 沙箱里的代理,用三行 bash 就能读写宿主机 workspace 之外的任意文件,漏洞编号 CVE-2026-77179,CVSS 4.0 评分 9.4。修复已在 Docker Sandboxes 0.42.0 和 Docker Desktop 4.88.0 落地。本文说清三件事:谁受影响、漏洞怎么发生、怎么自查升级并用清单验收。

Docker 沙箱逃逸两个漏洞速览:CVE-2026-77179 与 CVE-2026-79994

一、先认识两个组件:Docker Sandboxes 与 Docker VMM

Docker Sandboxes 是 Docker 给 AI 编码代理准备的隔离环境,用 sbx 命令管理:每个代理(Claude Code、Codex、Gemini CLI、OpenCode 等)跑在自己的 microVM 里——独立内核、独立文件系统、独立 Docker 引擎,宿主机的项目目录以 workspace 形式挂载进去。官方文档把它拆成五层隔离:hypervisor、网络、Docker Engine、workspace、凭据代理。

Docker VMM 则是 Docker 自研的轻量 hypervisor。Docker Desktop 从 4.86 开始在 Mac 和 Windows 上提供这个选项(Mac 上 4.35–4.85 时期用的是 libkrun)。据研究者披露,Docker VMM 计划在 2026 年 10 月底成为 Docker Desktop 的默认选项。

为什么值得单独写一篇?Docker 官方文档写得很直白:hypervisor boundary is the isolation control, not in-VM privilege separation——代理在 VM 里带 sudo、装包、执行命令都在预期之内,虚拟机边界才是那唯一一道墙。这次墙被绕过去了:逃逸操作以宿主机上运行虚拟机的账户(VMM 用户)权限执行,可读改宿主机文件,CVE 记录里还写着"可能进一步导致宿主代码执行"。

二、漏洞机制:一段没被清理的路径字符串

挂载目录走的是 virtio-fs,文件服务跑在宿主机一侧。guest 第一次触碰某个路径时,服务器回一个 nodeid(它自己记账用的编号);之后 guest 都按 nodeid 请求,服务器每次都要把文件重新找到:先按 inode 走 macOS 的 volfs,找不到就回退到"第一次记录下来的路径字符串"。

研究者的利用链恰好卡在这个回退上,可以拆成五步:

  1. 在共享目录里建一个与目标同名的文件,并保持打开——拿到句柄,同时让服务器记住 nodeid;
  2. 删掉文件,再删掉父目录——volfs 那条路没了,服务器手里只剩路径字符串;
  3. 把父目录换成一个符号链接,指向宿主机上想读写的目录;
  4. 通过还握着的句柄发起读写;
  5. 服务器重新解析那段字符串:路径前缀看起来还在挂载目录里,放行;但内核接着解析时跟了符号链接,请求最终落在 workspace 之外的文件上。

研究者给出的最小复现(简化自公开文稿):

mkdir pv && : > pv/.canary && exec 9< pv/.canary   # 建文件并保持打开
rm pv/.canary; rmdir pv; ln -s /Users/Shared pv    # 删路径,父目录换成符号链接
echo CONFIRMED > /proc/self/fd/9                   # 经句柄写到挂载目录之外

只有在自有测试环境验证修复是否生效时才该重放这段代码,别在生产机上试。漏洞归类 CWE-59(链接跟随),CVSS 4.0 评分 9.4,影响 Docker Sandboxes 0.28.0 至 0.41.x(macOS);Docker Desktop 则要启用 Docker VMM 才在影响范围。"workspace 之外的符号链接不跟随"本来是 Docker 文档里的承诺,这次是通过"先删掉、再换链接"的时间差,让一次本应安全的路径重解析变成了越界访问。

三、同一个版本还修了第二个:CVE-2026-79994

0.42.0 还包含第二个修复:沙箱连接宿主 Unix domain socket 的中继。它的逻辑是"先校验 socket 路径在授权 workspace 内,然后拿路径名去连接"——校验和连接之间存在窗口,guest 在此期间把路径中某一级目录换成符号链接,连接就会落到 workspace 之外的任意 AF_UNIX socket 上,暴露数据或调起宿主侧能力。这个漏洞 CVSS 8.7,影响 0.37.0 到 0.41.9,修复同样在 0.42.0。

两个漏洞合起来看是同一类味道:check-then-use。文件共享层只要"校验用路径、操作用路径、中间还可能被换",就迟早出事——这不是 virtio-fs 独有的问题,是这类设计的通病。

四、时间线与影响判断

时间线:8 月 12 日报告 → 7 小时内收到回复 → 约 31 小时后修复提交 → 8 月 24 日 Docker Desktop 4.88.0 发布(随带修复组件)→ 9 月 7 日 Sandboxes 0.42.0 发布 → 9 月 15 日 CVE 记录公开 → 9 月 17 至 19 日公开分析放出。

截至发稿,Docker 没有报告在野利用,CISA 对这条 CVE 的评估也是"无已知利用"、未进 KEV 名单。但两点值得注意:第一,利用的前提只是"沙箱里已经有恶意代码"——一个投毒的依赖、一个被注入提示词的代理就够,而防住这个本来就是沙箱存在的意义;第二,Docker VMM 预计 10 月底在 Docker Desktop 里转正为默认,受影响人群只会变多。CVSS 9.4 加上边界失效,升级优先级应该排在前面。

Docker 沙箱逃逸处置流程:从清点到验收

五、自查:你的机器在不在影响范围

按组件分开核对,Mac 用户重点看这几项:

  • 用 Docker Sandboxes 的:执行 sbx version,低于 0.42.0 就受影响;sbx version --json 还能顺带看后端状态,适合写进巡检脚本。用 sbx ls 可以列出手上的沙箱。
  • 用 Docker Desktop 的:打开 Settings → General → Virtual Machine Manager,看选的是 Docker VMM 还是 Apple Virtualization framework。选了 Docker VMM 且版本低于 4.88.0 才在影响范围;用 Apple Virtualization framework 的不涉及。
  • Windows 与 Linux:这条 CVE 标注为 macOS 场景;对应平台不涉及这个特定问题,照常保持更新即可。

六、修复与缓解

首选升级,两条线都升到位:

  • Docker Sandboxes:Homebrew 用户执行 brew upgrade docker/tap/sbx(或重跑一次 brew install docker/tap/sbx);手动安装的去 docker/sbx-releases 下载新包替换。升级后 sbx version 复核,目标不低于 0.42.0。
  • Docker Desktop:应用内 Check for Updates 升到 4.88.0 以上(4.89.0 已于 8 月 31 日发布,保持最新更稳);企业环境可以走 Settings Management 批量推送。

不能立即升级时,Desktop 有一条临时缓解:把 Virtual Machine Manager 切回 Apple Virtualization framework——漏洞出在 Docker VMM 的文件服务里,不用它就不在这条路径上;代价是放弃 Docker VMM 的性能收益。Sandboxes 没有等价开关,只能升级;确实升不了的,把敏感目录从 workspace 挪走,也别在旧版本里跑来历不明的代理。

升级完做一次复验:sbx version 确认版本号;有条件的团队可以在自有沙箱里重放第二节那段最小代码,确认已写不出挂载目录之外。

七、常见问题排查表

现象可能原因处理方向
sbx version 还是旧版本Homebrew 未刷新,或手动安装的二进制没替换重跑升级或安装命令,复核 which sbx 指向的路径
Docker Desktop 没有更新提示更新是渐次滚动发布,未轮到本机等待推送或从官网手动下载安装包;企业环境用 Settings Management
切换 VMM 后容器或数据库起不来Docker VMM 与 Apple Virtualization framework 存在已知差异先切回原配置恢复业务,再对照官方已知问题列表排查
不确定自己是否受影响把平台和组件两个条件混在一起看了拆开核对:Mac 且开 Docker VMM,或 sbx 低于 0.42.0,才在影响范围
旧版本期间跑过不可信代理无法排除已经发生过越界读写按事件响应思路排查宿主机敏感文件、轮换相关凭据、收敛代理权限

八、验收清单

  • sbx version 不低于 0.42.0,环境里已无旧版本沙箱 CLI;
  • Docker Desktop 不低于 4.88.0,Mac 用户核对过 Virtual Machine Manager 的设置与变更记录;
  • 无法立即升级的机器:缓解与例外逐项登记(切回 Apple Virtualization framework、缩小 workspace 暴露面);
  • 曾在受影响版本里跑过不受信代理的机器,进入安全排查清单;
  • 版本、变更时间与责任人记录归档。

这次运气不算差:问题在公开披露前就被修掉,目前也没有在野利用的证据。但 virtio-fs 这类"路径字符串加重新解析"的组合,本质上是把安全押在时序上,和历年容器逃逸的经典案例同属一个家族。对用 AI 代理的团队,两点提醒:虚拟机边界是底线,权限收敛是日常;版本巡检是每次披露后的固定动作。

🔕 评论已关闭