CVE-2020-15257：Containerd虚拟环境逃逸

前置知识

Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等。

• containerd-shim 的作用：它是 containerd 用来管理每个容器的“辅助进程”，负责容器生命周期管理。它通过一个 抽象 Unix 域套接字 (Abstract Unix Domain Socket)* 暴露 API 供 containerd 调用。
• 抽象套接字的特性：与文件系统上的套接字不同，抽象套接字不依赖文件系统，而是与网络命名空间绑定*。这意味着，只要两个进程在同一个网络命名空间内，就能访问该套接字，即使无法访问具体的文件路径

漏洞前题

1. 漏洞版本：containerd 版本需低于 1.3.9 或 1.4.3。
2. 容器启动参数：目标容器必须使用 --net=host 参数启动，与宿主机共享网络命名空间。
3. 容器内权限：你需要在容器内拥有 root 权限（UID 0）

漏洞原理

Containerd 是一个控制 runC 的守护进程，提供命令行客户端和API，用于在一个机器上管理容器。在特定网络条件下，攻击者可通过访问containerd-shim API，从而实现Docker容器逃逸。Containerd是行业标准的容器运行时，可作为Linux和Windows的守护程序使用。在版本1.3.9和1.4.3之前的容器中，容器填充的API不正确地暴露给主机网络容器。填充程序的API套接字的访问控制验证了连接过程的有效UID为0，但没有以其他方式限制对抽象Unix域套接字的访问。这将允许在与填充程序相同的网络名称空间中运行的恶意容器（有效UID为0，但特权降低）导致新进程以提升的特权运行。

换句话说就是：containerd-shim 组件通过“抽象Unix域套接字”暴露管理API，且访问控制不严。当容器使用主机网络模式并以root运行时，容器内攻击者就能访问该API，进而控制宿主机。

漏洞复现

环境验证

• 容器与宿主机共享了网络命名空间（使用了 --net=host 或 hostNetwork: true）。
• 容器内进程可以访问该套接字，满足漏洞利用的前提条件。
• 遇到问题：containerd 1.2.6 的 shim（老 Go 编译）绑定的 abstract socket 实际名称是 .../shim.sock\x00（末尾带一个 NUL 字节*，在 /proc/net/unix 里显示为末尾多一个 @）。Go 1.22 起，运行时不再给 abstract unix socket 地址追加末尾 NUL ，而 CDK 源码里拨号写的是 net.Dial("unix", "\x00"+sock) —— 老 Go 编译时会隐式补上 \0 能连通，go1.22.2 编译后拨的地址就少了这个 \0，名称不匹配 → connection refused。

监听端口

反弹shell