容器逃逸漏洞
用途限制声明，本文仅用于网络安全技术研究、教育与知识分享。文中涉及的渗透测试方法与工具，严禁用于未经授权的网络攻击、数据窃取或任何违法活动。任何因不当使用本文内容导致的法律后果，作者及发布平台不承担任何责任。渗透测试涉及复杂技术操作，可能对目标系统造成数据损坏、服务中断等风险。读者需充分评估技术能力与潜在后果，在合法合规前提下谨慎实践。
容器逃逸漏洞再linux上比较常见，容器化环境主要部署在linux上，这里来详细介绍容器逃逸漏洞。
容器逃逸漏洞是指攻击者利用容器化环境（如 Docker、Kubernetes、Containerd）的隔离机制缺陷、配置错误或底层内核漏洞，突破容器的资源隔离边界，获取宿主机（Host）的操作权限（通常是 root 权限）的一类高危漏洞。容器的安全依赖于 Linux 内核的隔离技术（Namespace、Cgroups、Capabilities 等），若这些机制被绕过或存在缺陷，就可能导致逃逸。
一、容器逃逸的核心分类
根据逃逸利用的核心路径，可分为 4 大类，每类包含典型漏洞案例和利用逻辑：
1. 利用容器隔离机制缺陷逃逸
容器的隔离依赖 Linux 内核的Namespace（命名空间） 和Cgroups（控制组），若这些机制存在设计缺陷或使用不当，攻击者可直接绕过隔离。
| 漏洞类型 | 典型案例 | 原理说明 | 影响场景 |
| Namespace 逃逸 | CVE-2022-0492（OverlayFS） | OverlayFS（容器常用存储驱动）的copy_up机制存在权限绕过，容器内可修改宿主机文件系统 | Docker、Containerd 等使用 OverlayFS 的环境 |
| Cgroups 权限滥用 | Cgroups Release Agent 逃逸 | 攻击者通过修改 Cgroups 的release_agent（释放代理）路径，将其指向容器内的恶意脚本，当 Cgroups 触发释放时，宿主机以 root 执行该脚本 | 容器拥有CAP_SYS_ADMIN权限（非默认） |
| PID Namespace 逃逸 | 宿主机 PID 泄露 + 信号注入 | 若容器启动时未隔离 PID Namespace（--pid=host），容器内可看到宿主机所有进程，通过向宿主机 root 进程注入信号或代码逃逸 | 特权容器（Privileged）或 PID Namespace 配置错误 |
2. 利用 Linux 内核漏洞逃逸
容器运行在宿主机内核之上，若宿主机内核存在未修复的高危漏洞（如 UAF、权限绕过），攻击者可在容器内触发漏洞，突破内核隔离获取宿主机权限。这类漏洞本质是Linux 内核漏洞在容器环境的延伸，但容器环境会降低利用门槛（无需物理机 / 虚拟机访问）。
| 典型漏洞 | 内核模块 | 逃逸逻辑 |
| CVE-2016-5195（Dirty COW） | 内存子系统 | 容器内触发 COW 机制的竞争条件，修改宿主机的只读文件（如/etc/passwd），添加 root 用户 |
| CVE-2021-41773（Apache HTTP Server） | 内核 Netfilter | 容器内通过恶意请求触发内核缓冲区溢出，执行宿主机内核态代码 |
| CVE-2022-2588（Netfilter UAF） | 内核 Netfilter | 容器内构造特殊 Netfilter 规则，触发双重释放漏洞，获取宿主机 root 权限 |
3. 利用容器配置错误逃逸
这类逃逸并非依赖 “漏洞”，而是由于管理员 / 开发者对容器配置的安全选项忽略，导致隔离机制失效，是实际环境中最常见的逃逸场景。
| 配置错误类型 | 利用逻辑 | 典型操作示例 |
| 特权容器（Privileged） | 启动容器时添加--privileged参数，容器会获得宿主机几乎所有 Capabilities 权限，可直接挂载宿主机文件系统（如/dev/sda1） | 容器内执行：mount /dev/sda1 /mnt，直接修改宿主机/mnt/etc/passwd |
| 宿主机目录挂载不当 | 将宿主机敏感目录（如/etc、/var/run/docker.sock）以rw（可写）权限挂载到容器内，攻击者可修改宿主机文件或控制 Docker 服务 | 挂载/var/run/docker.sock后，容器内通过docker run启动新特权容器，挂载宿主机根目录 |
| Capabilities 权限过度授予 | 容器默认仅保留基础 Capabilities（如CAP_NET_RAW），若额外授予CAP_SYS_ADMIN（系统管理权限），攻击者可利用该权限创建宿主机级别的命名空间或修改内核参数 | 容器内执行：mount -t proc proc /host/proc，读取宿主机进程信息并注入代码 |
| 容器镜像使用 root 用户 | 容器默认以 root 用户运行（非默认，但常见配置），若结合其他缺陷（如文件挂载），可直接操作宿主机文件 | 镜像中内置恶意脚本，挂载宿主机/root目录后修改~/.bashrc，宿主机 root 登录时触发 |
4. 利用容器 runtime 漏洞逃逸
容器 runtime（如 RunC、Containerd）是管理容器生命周期的核心组件，若 runtime 本身存在漏洞，攻击者可通过容器内操作篡改 runtime 逻辑，实现逃逸。
| 典型漏洞 | 影响组件 | 逃逸逻辑 |
| CVE-2019-5736（RunC） | RunC | 容器内进程可通过/proc/self/exe（指向宿主机的runc二进制）修改runc文件，当宿主机执行runc exec等命令时，触发恶意代码执行 |
| CVE-2023-28840（Containerd） | Containerd | Containerd 的cri组件处理镜像时存在路径遍历，攻击者可通过恶意镜像将文件写入宿主机任意路径（如/etc/cron.d），触发定时任务执行 |
| CVE-2022-24769（Docker Desktop） | Docker Desktop（Windows/macOS） | Windows/macOS 下的 Docker Desktop 存在权限绕过，容器内可访问宿主机的 Windows 文件系统（如C:盘），修改系统配置 |
二、如何判断容器环境是否存在逃逸风险？
除了 “内核漏洞”（需依赖漏洞扫描工具），其他类型的逃逸风险可通过容器内自查和宿主机检测两步判断，操作门槛低且效果直接：
1. 容器内自查：判断当前容器是否存在逃逸条件
在容器内执行以下命令，检查是否存在配置缺陷或隔离失效：
| 检查项 | 执行命令 | 风险判断标准 |
| 1. 是否为特权容器 | grep -E '^CapEff:' /proc/self/status 或 capsh --print | 若输出包含0000003fffffffff（全 Capabilities），或capsh显示Current: = cap_setpcap,cap_setuid,cap_setgid,...（包含CAP_SYS_ADMIN等高危权限），则为特权容器 |
| 2. 宿主机目录挂载情况 | mount 或 cat /proc/mounts | 若存在挂载/var/run/docker.sock、/etc、/proc/sys、/dev/sda1（宿主机磁盘）等路径，且权限为rw（可写），则存在风险 |
| 3. PID Namespace 隔离 | ps aux 或 ls /proc | 若能看到宿主机进程（如systemd、sshd，PID 通常 < 1000），则 PID Namespace 未隔离（--pid=host配置） |
| 4. Cgroups 配置 | ls /sys/fs/cgroup/ 或 cat /sys/fs/cgroup/cpu/release_agent | 若release_agent路径可修改（非/bin/true），或 Cgroups 目录权限为w（可写），则存在release_agent逃逸风险 |
| 5. runtime 版本漏洞 | docker version（容器内若有 docker 客户端）或 cat /proc/1/comm（查看 runtime） | 若 RunC 版本 < 1.0.0-rc93（CVE-2019-5736）、Containerd 版本 < 1.6.18（CVE-2023-28840），则存在 runtime 漏洞 |
2. 宿主机检测：排查整体容器环境的逃逸风险
在宿主机上执行以下操作，发现全局风险配置：
| 检测目标 | 执行命令 | 风险判断标准 | |||
| 1. 特权容器列表 | docker ps --format '{{.ID}} {{.Names}} {{.Ports}}' --filter "privileged=true" | 输出非空则存在特权容器，需重点排查 | |||
| 2. 危险挂载容器 | `docker inspect --format '{{.Id}} {{.Mounts}}' $(docker ps -q) | grep -E '/var/run/docker.sock | /etc | /dev/sda'` | 输出非空则存在宿主机敏感目录挂载的容器 |
| 3. 内核漏洞排查 | uname -r（查看内核版本） + 漏洞数据库匹配 | 对比 CVE 数据库（如CVE Details），若内核版本包含未修复的高危漏洞（如 CVE-2022-0492、CVE-2021-41773），则存在风险 | |||
| 4. runtime 版本检查 | runc -v 或 containerd -v | 若版本低于安全版本（RunC ≥1.0.0-rc93，Containerd ≥1.6.18），需立即更新 |
三、容器逃逸的防御核心
禁用特权容器：除非绝对必要，否则不使用--privileged参数启动容器；若需部分权限，通过--cap-add仅授予最小必要的 Capabilities（如仅授予CAP_NET_BIND_SERVICE而非CAP_SYS_ADMIN）。
谨慎挂载宿主机目录：避免挂载/var/run/docker.sock、/etc、/proc/sys等敏感路径；若必须挂载，使用ro（只读）权限（如-v /host/data:/container/data:ro）。
及时更新组件：定期更新宿主机内核（修复内核漏洞）、容器 runtime（RunC/Containerd）、Docker/Kubernetes 版本（修复配置缺陷和 runtime 漏洞）。
使用非 root 用户运行容器：在 Dockerfile 中通过USER指令指定普通用户，或启动容器时添加--user参数（如docker run --user 1000:1000 ubuntu），降低容器内用户权限。
部署安全监控工具：使用 Falco、Aqua Security 等工具监控容器异常行为（如容器内挂载宿主机磁盘、修改/etc/passwd、执行mount命令），及时告警逃逸尝试。