漏洞背景

CVE-2024-0132 是 NVIDIA 官方披露的一个高危漏洞，影响 NVIDIA Container Toolkit 和 GPU Operator 组件。该漏洞允许攻击者在容器化环境或 Kubernetes 集群中通过 GPU 资源管理缺陷实现权限提升或容器逃逸，威胁云原生 AI 基础设施安全。

去年 9 月，Wiz Research 发现了广泛使用的 NVIDIA 容器工具包中存在的一个严重安全漏洞，编号为 CVE-2024-0132，该工具包为容器化的 AI 应用程序提供对 GPU 资源的访问权限。wiz最初博客文章故意含糊其辞，因为该漏洞被长期禁止发布，以便 NVIDIA 和云提供商能够解决这个问题。该漏洞使控制由易受攻击的工具包执行的容器映像的攻击者能够摆脱容器的隔离并获得对底层主机的完全访问权限，对敏感数据和基础设施构成严重风险。

ps： 参考 avd.aliyun.com 也未对这个漏洞进行高分评估。

https://avd.aliyun.com/detail?id=AVD-2024-0132

漏洞概述

该漏洞使恶意攻击者能够将主机的根文件系统挂载到容器中，从而授予对主机所有文件的无限制访问权限。此外，通过访问主机的容器运行时 Unix 套接字，攻击者可以启动特权容器并实现完全主机入侵。在我们的演示中，我们通过在容器内挂载主机的文件系统来利用此漏洞，然后利用访问权限docker.sock启动特权容器并完全入侵主机。

我们的研究发现了多个存在漏洞的云服务提供商，NVIDIA 的容器工具包可利用这些漏洞。在某些情况下，该漏洞可完全攻陷跨多个租户共享的 Kubernetes 集群。在这篇博文中，我们介绍了该漏洞的技术细节，并讨论了针对 Docker 和 gVisor 利用该漏洞的不同方法。

软件架构

下图概述了大多数环境中创建容器的过程：

在此设置中，Docker 接收用户输入以构建容器配置，包括资源分配和环境设置。然后，Docker 与 containerd 通信，后者管理容器生命周期、处理镜像传输并设置网络。containerd 利用 runc 根据开放容器计划 (OCI) 规范创建和运行容器。runc 设置命名空间和 cgroup 以隔离容器环境并启动容器内的主要进程

了解 NVIDIA 的容器工具包

NVIDIA 容器工具包是一组开源软件库和工具，用于配置容器以使用 GPU 资源。NVIDIA 的工具包被 AI SaaS 供应商、运行 AI 模型的公司和端点设备广泛使用。

NVIDIA 容器工具包支持多种容器运行时，例如 Docker、Containerd (Kubernetes)、CRI-O 和 Podman。本篇博文将重点介绍 Docker，但包括 Containerd 和 CRI-O 在内的其他容器也受到CVE-2024-0132的影响。请注意，由于使用容器设备接口 (CDI) 会完全绕过受影响的代码，因此使用该接口的环境不会受到影响。例如，这包括 Podman，它为使用 CDI 请求设备提供本机支持。

下图 我们将 NVIDIA Container Toolkit 添加到组合中：

• 在安装过程中， NVIDIA Container Toolkit 会更改 Docker 守护程序配置并将自身设置为默认容器运行时。

• 当用户执行docker run时，Docker 将调用nvidia-container-runtime二进制文件来创建并启动容器。docker 生成的容器定义由nvidia-container-runtime修改以添加新的预启动hook，然后传递给系统的runc。

• runc执行 标准容器初始化步骤，然后调用之前添加的预启动hook。

• nvidia-container-runtime-hook负责将设备、库和二进制文件安装到容器进程中，并使用nvidia-container-cli ( libnvidia-container )执行大部分这些操作。

• 预启动挂钩完成后，控制权将返回给runc，它继续进行容器初始化，设置安全边界并最终调用容器的 ENTRYPOINT。

NVIDIA Container Toolkit攻击面

在nvidia-container-runtime-hook执行期间，容器处于早期初始化阶段，这意味着容器完全运行时适用的关键安全控制和操作系统限制尚未生效。

容器的文件系统上会发生重大且危险的操作，潜在的攻击者可能会操纵文件和设置。此外，这些操作是从主机执行的。这种设置意味着，如果在这些操作期间利用了文件系统漏洞，攻击者可能会获得直接访问权限，从而在主机文件系统本身上执行操作。

在审查 NVIDIA Container Toolkit 源代码时，我们发现在将文件挂载到容器中的方式中存在检查时间/使用时间 (TOC/TOU) 漏洞libnvidia-container 。我们将在下一节中概述的漏洞会诱使libnvidia-container我们将目录挂载到容器内，从而有效地执行容器逃逸。

有意思的挂载

当使用 NVIDIA Container Toolkit 运行时运行容器时，我们观察到几个有趣的挂载：

检查 mount 命令的输出，我们发现 NVIDIA 容器工具包已将多个库安装到容器中。进一步调查容器工具包调试日志，发现了一些看似有希望的相关操作：

源码分析

让我们回顾一下源代码，以便更好地理解nvidia-container-cli如何将文件挂载到客户容器中。主要逻辑在于nvc_driver_mount函数，该函数相当大，通过调用 来完成大部分挂载mount_files。

挂载可分为两大类：将资源从主机挂载到容器中以及将资源从容器挂载到自身（cnt->cfg.libs_dir）。wiz决定专注于后者，因为我们怀疑我们可能能够cnt->lib通过修改容器文件系统内的文件、路径或符号链接来控制挂载源（ ）。事实证明，此机制用于向后兼容。此过程很难实现，因为主机必须代表客户容器处理文件系统操作，同时确保源位置和目标位置均保持在容器允许的命名空间内。

由于挂载操作是从主机执行的，因此目标根目录 ( cnt->cfg.rootfs) 显示如下：/var/lib/docker/overlay2//merged。如果我们设法在此路径之外挂载源并在此路径内设置目标，我们就可以读取容器命名空间之外的文件。

基本上，nvc_driver_mounts 复制了 cnt->libs，并使用 filter_libraries 对它们进行筛选，然后调用 mount_files 将它们安装到适当的位置。filter_libraries 并不十分严格；它只是在库文件名中寻找特定版本号的库。

挂载的源路径 cnt->libs 在初始化（nvc_driver_info_new）期间由 find_library_paths 设置。它使用 glibc 的 glob 来搜索匹配模式：/usr/local/cuda/compat/lib*.so.* 的路径。这些路径随后被 nvc_driver_mount 安装，如上所述。

由于我们可以控制容器的文件系统，我们也可以控制xglob函数返回的路径。有趣的是，并没有检查来确保xglob返回的路径是常规文件，尽管正则表达式明确地只期望返回文件。这个疏忽允许我们在稍后讨论利用时植入目录，这将非常有用。

此函数还调用path_resolve，该函数遵循符号链接和点点（..）条目以返回绝对路径。但是，此路径不是主机路径（它不以cnt->rootfs开头）；而是客容器路径——例如，“/”指的是容器根。这些路径随后被返回并最终存储在cnt->libs中。

漏洞

我们注意到，在初始化过程中会发生路径解析，而我们在挂载操作之间仍然可以操纵文件系统布局。这是否能被利用呢？让我们来检查一下mount_files函数并探索我们的选项：

当nvc_driver_mount调用此函数时，参数如下：

root- 容器在主机上的根目录（/var/lib/docker/overlay2/<容器ID>/merged）。

dir - 取决于容器镜像的架构；对于x64，它将是/usr/lib64。

paths - 一个文件路径数组，我们可以在/usr/local/cuda/compat目录中控制，需要挂载到dir。

该函数本质上将/usr/local/compat/lib* .so .* 挂载到相同名称的文件名下，在我们的容器内/usr/lib64。如果我们能够使用符号链接或../../../../../../来操纵这些路径，我们将能够在容器外从/usr/lib64内的某个路径进行挂载。然而，这应该是不可能的，因为find_library_paths已经对所有路径进行了规范化处理。

最终的源挂载路径设置为根目录+paths[i]。我们可以利用循环并在迭代之间修改文件系统。由于我们控制整个文件系统，可以在操作之间植入一个替换下一个源的挂载目标，并确保下一个paths[i]是一个符号链接。

漏洞分析

运行此漏洞利用时，我们启动容器，其/usr/local/cuda/compat目录结构如下：

1. 1. libnvidia-ml.so.6 – 目录

libnvidia-ml.so.7 – 指向 ../../../../../../ （容器文件系统之外）的符号链接

1. 1. libnvidia-ml.so.7 – 常规文件

最初，当find_library_paths遍历时/usr/local/cuda/compat/，它仅检测到两个条目：一个名为libnvidia-ml.so.6和的目录libnvidia-ml.so.7，一个空的常规文件。

当我们输入 时mount_files，第一次迭代挂载/usr/local/cuda/compat/libnvidia-ml.so.6 到/usr/lib64/libnvidia-ml.so.6.我们有策略地将此目标路径植入为指向 的特制符号链接/usr/local/cuda/compat/，内核会跟随该链接。结果，目录/usr/local/cuda/compat/libnvidia-ml.so.6 被挂载在 上/usr/local/cuda/compat/，从而有效地替换了其内容。此时，与find_library_paths最初观察到的情况相比，文件系统已经发生了变化。现在，我们的libnvidia-ml.so.6 目录用新条目覆盖了 compat 目录。

在循环的第二次迭代中，函数尝试挂载/usr/local/cuda/compat/libnvidia-ml.so.7到/usr/lib64/libnvidia-ml.so.7。但是，libnvidia-ml.so.7不再是常规文件！它现在是一个符号链接，并且它不是find_library_paths初始化期间最初检测到的同一个文件。

当函数挂载时/usr/local/cuda/compat/libnvidia-ml.so.7，Linux 内核会解析路径中的任何符号链接。在本例中，libnvidia-ml.so.7实际上指向主机的文件系统根目录 ( ../../../../../../)。这会强制内核将/从主机挂载到/usr/lib64/libnvidia-ml.so.7容器内，从而有效地破坏容器隔离！

权限提升和 RCE

这种容器逃逸漏洞的一个令人沮丧的局限性是主机文件系统被挂载为只读。

尽管存在只读限制，但我们仍然可以与主机上的Unix套接字进行交互，因为它们不受此限制的影响。通过打开主机的docker.sock，我们可以启动新的特权容器。这成为了我们漏洞利用实现中的最后一步：

一旦我们运行了这个镜像并生成特权容器，我们就获得了对主机文件系统的不受限制的访问权限，包括完整的写入功能。这种提升的访问级别还允许我们监控网络流量、调试活动进程，并执行一系列其他主机级操作。

对gVisor的影响

Google 的 gVisor 是容器隔离的事实标准。它还支持 NVIDIA 容器工具包，以更安全的方式使用 GPU 容器。然而，我们确认该漏洞确实影响了 gVisor！这允许将主机上的文件和目录挂载到沙盒容器中，可能导致容器逃脱。

不过，在我们的测试中，我们发现通过 /run/docker.sock 进行的相同权限提升在某些具有 gVisor 的 Linux 发行版上可能无法直接起作用。利用需要进行调整才能在这些环境中生效。

关注我们，获取更多安全资讯和技术分析！

微信公众号: 黑伞安全

原文始发于微信公众号（黑伞安全）：揭秘NVIDIA AI安全漏洞：CVE-2024-0132深度剖析