容器逃逸漏洞

原创于 2025-09-15 23:03:40 发布 · 961 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#网络安全 #漏洞原理

漏洞原理专栏收录该内容

5 篇文章

订阅专栏

用途限制声明，本文仅用于网络安全技术研究、教育与知识分享。文中涉及的渗透测试方法与工具，严禁用于未经授权的网络攻击、数据窃取或任何违法活动。任何因不当使用本文内容导致的法律后果，作者及发布平台不承担任何责任。渗透测试涉及复杂技术操作，可能对目标系统造成数据损坏、服务中断等风险。读者需充分评估技术能力与潜在后果，在合法合规前提下谨慎实践。

容器逃逸漏洞再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），需立即更新