英語版で読む
技術約6分で読めます

NVIDIA Container ToolkitのTOCTOUによるコンテナエスケープとCDI移行

SecurityDockerGPUNVIDIAKubernetes
いけさん目次

TL;DR

影響 NVIDIA Container Toolkit 1.16.1 以前、GPU Operator 24.6.1 以前。マルチテナント基盤や外部イメージを実行する環境で、コンテナエスケープによるホスト完全掌握（CVSS 9.0 Critical）

対応 NVIDIA Container Toolkit 1.16.2 以降、または GPU Operator 24.6.2 以降へ更新。または Container Device Interface (CDI) へ切り替えて旧マウント機構を無効化

NVIDIAは2024年9月中旬、Security Bulletin 5582を公開し、NVIDIA Container ToolkitおよびNVIDIA GPU Operatorに存在する重大な脆弱性（CVE-2024-0132）の修正を発表した。
クラウドセキュリティ企業Wizの調査チーム（Shir Tamari氏ら）が報告したもので、共通脆弱性評価システムCVSS v3.1の基本値は9.0（Critical）と評価されている。

コンテナ内からGPUを利用可能にする際、ホストのGPUライブラリをコンテナ内へマウントする処理でTime-of-check Time-of-use（TOCTOU、検証から使用までの競合状態）が発生する。
悪意あるコンテナイメージを実行させられると、ホスト側のルートファイルシステム（/）全体がコンテナ内部へ誤ってマウントされ、ホスト上での任意コード実行や権限昇格、完全なホスト掌握（コンテナの隔離を破って抜け出すコンテナエスケープ）に至る。

影響を受ける製品と修正バージョン

対象となる製品およびバージョンは次の表のとおりとなる。

製品影響を受けるバージョン修正バージョン
NVIDIA Container Toolkit1.16.1 以前1.16.2 以降
NVIDIA GPU Operator24.6.1 以前24.6.2 以降

NVIDIA Container Toolkitは、DockerやPodman、containerdなどのコンテナランタイムからNVIDIA GPUへのアクセスを提供する中核コンポーネントを担う。
Kubernetes環境では、GPUドライバやランタイムの設定を自動管理するNVIDIA GPU Operatorを通じてクラスタ全体に導入されるケースが多い。

この欠陥は、コンテナイメージを外部から持ち込める環境で特に深刻度を増す。
マルチテナントなAI・機械学習（AI/ML）実行基盤や、送信された任意のコンテナイメージを自動ビルド・実行するCI/CDパイプライン、クラウド型の開発環境では、攻撃者が細工したコンテナを起動するだけで同一ノード上の全コンテナとホスト自身を侵害できる。

ライブラリマウント処理におけるTOCTOU競合の仕組み

NVIDIA Container Toolkitはデフォルト構成において、コンテナ起動時にフック（nvidia-container-cli）を実行し、ホスト側のGPU関連ファイルをコンテナ内へ注入する旧来の方式を採用している。
この初期化シーケンスにおいて、/usr/local/cuda/compat配下のCUDA互換ライブラリや各種GPUライブラリをコンテナへマウントする処理が走る。

CWE-367として分類されるTOCTOU競合状態は、対象のリソースを検査（Check）した時点と、実際にそのリソースを使用（Use）する時点との間に微小なタイムラグが生じることで発生する。
ツールキットはコンテナイメージ内のマウント先パスを事前に検証するが、検証処理と実際のマウント処理がアトミック（不可分な単一処理）に保護されていない。

攻撃者は、マウント対象となるライブラリのパスにあらかじめ特殊なシンボリックリンク（特定のファイルやディレクトリを指し示す参照リンク）を配置した悪意あるコンテナイメージを用意する。
ツールキットがパスの安全性を確認した直後、マウントを実行する瞬間にシンボリックリンクが解決されると、ホスト側のルートファイルシステム（/）や親ディレクトリ全体がマウント先として取り込まれてしまう。

コンテナエスケープの実行フロー

悪意あるイメージの展開からホスト掌握に至る一連の流れを図に示す。

flowchart TD
  A["悪意あるコンテナイメージの実行要求<br/>（特殊なシンボリックリンクを内包）"] --> B["nvidia-container-cli が起動<br/>（フックによる初期化処理）"]
  B --> C["マウント対象パスの安全性を検査<br/>（Checkフェーズ）"]
  C --> D["検証とマウントの隙間にシンボリックリンクを評価<br/>（TOCTOU競合）"]
  D --> E["ホストのルートファイルシステム全体をコンテナ内にマウント<br/>（Useフェーズの誤動作）"]
  E --> F["コンテナ内からホストのルートファイルシステムへアクセス<br/>（読み書き権限を取得）"]
  F --> G["ホスト上の重要設定改ざんや制御ソケット経由でのコード実行<br/>（任意コード実行と権限昇格）"]
  G --> H["完全なコンテナエスケープ達成<br/>（ホストおよび他コンテナの掌握）"]

ルートファイルシステム露出からホスト掌握への経路

コンテナ内部からホストのルートファイルシステム（/）に対する読み書き権限を取得できた場合、攻撃者は多様な手段でホストの制御権を奪取する。

ホストのファイルシステムが手に入ると、/etc/shadowの改ざんや管理者アカウントへのSSH公開鍵の追加、cronジョブやsystemdサービス定義の書き換えが可能となる。
さらに、ホスト上で動作するコンテナエンジンの制御ソケット（/var/run/docker.sockやcontainerd.sock）に直接アクセスし、特権コンテナを新設してホスト上での任意コード実行（RCE）を成立させる手法も取れる。

これにより、コンテナによる隔離空間は完全に無力化され、攻撃者はホスト全体のroot権限を取得する。
同じGPUノード上で稼働している他テナントのコンテナプロセス、メモリ上のデータ、機密情報やAPIキーのすべてが漏洩および改ざんの危険に晒される。

パッケージ更新とContainer Device Interfaceへの移行

本脆弱性を解消するには、各ディストリビューション向けに提供されている修正版パッケージへの即時更新を実施する。
APT環境（UbuntuやDebian）では、リポジトリのインデックスを更新した上でパッケージを最新化する。

sudo apt-get update
sudo apt-get install --only-upgrade nvidia-container-toolkit

RPM環境（RHELやCentOS）では、dnfまたはyumを用いて更新を適用する。

sudo dnf upgrade nvidia-container-toolkit

KubernetesクラスタでNVIDIA GPU Operatorを運用している場合は、Helm経由でバージョン24.6.2以降へアップグレードを行う。

helm repo update
helm upgrade --reuse-values -n gpu-operator gpu-operator nvidia/gpu-operator --version v24.6.2

直接のバージョンアップに加えて、Container Device Interface（CDI）への移行も有効な対策となる。
CDIは、コンテナランタイムがGPUなどのデバイスを安全かつ宣言的にコンテナへ注入するための標準仕様を指す。

従来のNVIDIA Container Toolkitで脆弱性の温床となった動的フックや危険なライブラリ探索機構をCDIは使用しない。
CDI仕様に基づいて生成された静的なJSON仕様書をコンテナランタイムが直接読み込んでデバイスを割り当てるため、TOCTOU競合が発生する余地自体が存在しない。

CDI仕様書を生成するには、ツールキット付属のコマンドを実行する。

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

生成された仕様書を確認し、Dockerデーモン（daemon.json）やcontainerdの設定（config.toml）でCDIモードを有効化すれば、脆弱な旧式マウント処理を完全に切り離した状態でGPUコンテナを安全に運用できる。