Docker 与 Kubernetes 核心运行时 runC 曝三高危漏洞：攻击者可实现容器逃逸并获取主机 root 权限

runC 作为 Docker 和 Kubernetes 等容器平台的基础容器运行时，近日被披露存在三个高危安全漏洞（CVE-2025-31133、CVE-2025-52565、CVE-2025-52881）。这些漏洞允许攻击者在特定条件下绕过容器隔离机制，写入主机 /proc 目录，最终实现容器逃逸并获取主机系统 root 权限。

上图：Kubernetes 整体架构（左）与 runC 在容器运行时栈中的位置（右）。runC 是 OCI 标准的参考实现，负责底层容器进程创建、命名空间配置和资源隔离。

runC 简介

runC 是一款轻量级、命令行式的容器运行时，同时也是开放容器倡议（OCI）的参考实现。它主要负责执行以下底层操作：

• 创建容器进程
• 配置 Linux 命名空间（namespaces）
• 设置挂载点（mounts）
• 管理控制组（cgroups）

Docker、containerd、Kubernetes 等上层工具均通过调用 runC 来启动和运行容器。

三个漏洞详细分析

这三个漏洞的核心共同点是：攻击者可诱导 runC 将主机敏感文件以可写模式挂载到容器内，从而绕过隔离，实现对 /proc 文件系统的写入控制。

• CVE-2025-31133（影响所有 runC 版本）： runC 使用绑定挂载 /dev/null 来“屏蔽”主机敏感文件（如 /proc 下的关键条目）。攻击者在容器初始化阶段将 /dev/null 替换为指向目标文件的符号链接（symlink），导致 runC 将攻击者控制的文件以读写模式挂载到容器中。攻击者随后可写入 /proc 目录，实现容器逃逸或主机崩溃。

🐳 Docker Bind Mounts vs Volumes: What's the Difference? - DEV Community

上图：Docker bind mount 工作原理示意。漏洞正是利用了类似绑定挂载的机制被符号链接滥用。

• CVE-2025-52565（影响 1.0.0-rc3 及后续版本）： 在处理 /dev/console 的绑定挂载时，存在竞争条件（race condition）或符号链接重定向问题。runC 可能在防护机制生效前，将非预期的目标挂载到容器内，导致关键 procfs 条目暴露可写权限。
• CVE-2025-52881（影响所有 runC 版本）： 攻击者可诱使 runC 向 /proc 目录执行写入操作，该操作会被重定向至攻击者控制的目标文件。在部分版本中，甚至能绕过 Linux 安全模块（LSM，如 AppArmor/SELinux）的重新标记防护，将普通写入转化为对 /proc/sysrq-trigger 等危险文件的任意写入。

GitHub - Aditya-1208/linux_kernel_modules: Walkthrough of steps for making custom linux kernel modules, interacting with kernel space and understanding how proc file system works in linux. Programming-Project of Chapter-2 of Operating System Concepts :

上图：Linux /proc 文件系统在用户空间与内核空间的交互示意。漏洞主要针对 procfs 的写入控制。

受影响版本与修复

• CVE-2025-31133 和 CVE-2025-52881：影响所有已知 runC 版本。
• CVE-2025-52565：影响 runC 1.0.0-rc3 及之后版本。
• 已修复版本：runC 1.2.8、1.3.3、1.4.0-rc.3 及更高版本已发布补丁。请尽快升级。

漏洞利用条件与实际风险

安全研究人员强调，利用这些漏洞需要攻击者具备以自定义挂载配置启动容器的能力（例如通过恶意容器镜像或精心设计的 Dockerfile）。

截至目前，尚未发现这些漏洞在真实生产环境中被主动利用的报告。但攻击者可通过监测可疑的符号链接创建或异常挂载行为进行检测。

缓解措施建议（runC 官方与 Sysdig 等安全厂商推荐）：

• 为所有容器启用用户命名空间（user namespaces），并避免将主机 root 用户映射到容器内。Unix DAC（自主访问控制）权限可有效阻断攻击。
• 优先使用无 root 权限容器（rootless containers），降低逃逸后的损害。
• 结合 seccomp、AppArmor/SELinux、只读文件系统等额外安全机制。
• 定期更新 runC、containerd、Docker 和 Kubernetes 组件。

上图：容器逃逸攻击示意（左）与 Kubernetes Pod 安全上下文配置（右）。强化安全上下文是重要防御手段。

总结与建议

这三个漏洞再次提醒我们：容器隔离并非绝对安全边界。runC 作为底层运行时，其安全直接影响整个容器生态。强烈建议所有使用 Docker、Kubernetes 或 containerd 的用户和企业立即检查 runC 版本并应用最新补丁，同时采用“defense in depth”（纵深防御）策略，包括 rootless 运行、最小权限原则和持续的安全监控。

如果您的环境依赖自定义挂载配置，请特别关注容器镜像来源的可信度。