LWN：又一次从runc 容器中逃脱！

关注了就能看到更多这么棒的文章哦～

Another runc container breakout

By Joe Brockmeier
February 12, 2024
Gemini translation
https://lwn.net/Articles/961086/

再一次，runc 这个用于生成和运行 OCI 容器的工具由于一起高严重性的容器逃逸攻击而引起了人们的关注。此漏洞之所以引人注目有几个原因：它具有广泛的影响、在实际存在的容器里的持续困难、以特权用户身份运行容器的危险，以及此漏洞出现的部分原因可能是应对runc 中之前的一个容器逃逸漏洞而引发的。

runc 程序是最流行的 （但并非仅有的） 开放容器计划 (OCI) 容器运行时规范 的实现，可用在处理容器管理和编排工具（例如 Docker、Podman、Rancher、containerd、Kubernetes 等）这些运行容器的底层操作上。Runc 还发现了许多其他漏洞，最新的漏洞是 CVE-2024-21626—这是一个可能允许攻击者完全逃逸出容器并控制主机系统的漏洞。修复程序随 runc 1.1.12 一起发布，版本 1.0.0-rc93 到 1.1.11 都受此漏洞的影响。发行商正在反向移植此修复程序并根据需要发布更新。

分析（Anatomy）

Rory McNamara 将第一个漏洞报告给了 Docker，而之后经过 runc 的维护人员 Li Fu Bang 和 Aleksa Sarai 进一步研究的时候，他们发现了其他潜在的攻击可能性。自版本 1.0.0-rc93 起，runc 在主机命名空间中有一个（“泄漏的”）文件描述符被打开，指向 /sys/fs/cgroup ，然后它显示在容器命名空间内的 /proc/self/fd 中。尽管通常都会会关闭主机命名空间的文件描述符，也还是可以通过将容器的工作目录设置为泄漏的文件描述符来保持此引用的活动状态。这允许容器拥有容器自身之外的工作目录，并完全访问主机文件系统。runc 针对 CVE 的安全公告 描述了几种可以利用此漏洞的攻击方式，所有这些攻击都可能允许攻击者完全控制主机系统。

Mohit Gupta 对该漏洞进行了分析，并报告说尝试使用恶意 Dockerfile 在场景中将工作目录设置为 "/proc/self/fd/7/"，大约四次尝试后才成功启动容器。因为 runc 没有验证工作目录是否在容器内，所以容器内的进程就可以访问主机文件系统。例如，如果攻击者成功地猜测到正确文件描述符并将其工作目录设置为 "/proc/self/fd/7"，他们就可以运行 "cat ../../../../etc/passwd" 这样的命令，并获得系统上所有用户的列表（有可能还有破坏性更大的攻击方式）。

Sarai 在公告中指出，如果使用 Docker 或 Kubernetes 等运行时，就可以远程利用此漏洞，因此可被视为一个严重的漏洞，""任何有启动容器镜像权限的人都可以攻击（而且在 Docker 的情况下，可以利用 ONBUILD 从 Dockerfiles 内部加以利用）"". 在 Snyk 博客中，McNamara 演示了如何利用此漏洞 使用的是 "docker build" 或 "docker run"，而 Gupta 的分析演示了某人如何将镜像部署到 Kubernetes 集群中，或使用恶意 Dockerfile 通过 "docker build" 或类似依赖 runc 的工具破坏 CI/CD 系统。McNamara 写道，更糟糕的是，"访问权限将与正在使用的容器化解决方案（例如 Docker 引擎或 Kubernetes）相同。通常来说这就是 root 用户，因此有可能通过提升磁盘访问权限来实现完整的 host root 命令执行".

这并不是 runc 第一次出现这种类型的漏洞，它还在 2019 年 2 月报出了一个容器逃逸漏洞（CVE-2019-5736）。这个问题导致 Sarai 做了 openat2() 的工作，其目的是限制攻击者可能控制的路径的打开方式。因此，从“趣味性”来说，这挺有意思的，无论如何，Sarai 提及“runc 中 switch to openat2(2) 是导致有 fd 泄漏其中的一个原因使这个问题在 runc 中可被利用”」。

虽然这个漏洞已经得到解决，但 Sarai 也写道，需要做更多工作来 停止与在主机上保持对特定链接的控制（例如 =/proc/self/exe=）有关的策略（例如 /proc/self/exe），然后在容器启动后写入它。他指出他已经修改了 runc 中的设计，但目前仍然“在尝试各种原型”。

其他 OCI 运行时

虽然已经确认运行时存在漏洞，但在说明中也提到了对其他运行时的警告。Sarai 写道，“其他几种容器运行时要么可能容易受到类似攻击，要么对这类攻击没有足够的防护”。Sarai 提到了 crun（一种用 C 实现的容器运行时Podman 默认使用）、youki（一种用 Rust 实现的容器运行时）和 LXC。

Sarai 指出，其他运行时均不会对它们各自的“runc init”对应项泄露有用的文件描述符，但对于确保关闭所有非 stdio 文件及容器的工作目录位于容器内部这些方面，他发现 crun 和 youki 存在缺陷。LXC 也无法确保工作目录位于容器内部。他建议其他运行时的维护人员通读 runc 泄露的文件描述符的补丁。尽管这些实现上是无法利用这个漏洞的（“据我们所知”），但它们存在以下问题，若要防止将来出现类似攻击，可加以解决。

好消息是，尽管这些年来出现过许多容器漏洞，但迄今我们尚未发现这些缺陷被广泛在 exploit 中利用的报道。这里是否要归功于容器运行时维护人员和安全报告者的警惕态度、受信任容器镜像的规范使用、使用 AppArmor 和 SELinux 等技术、利用这些缺陷来实施现实世界攻击的难度，还是所有因素皆有，目前尚不清楚。当然，这不意味着这些威胁不存在。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～