出典：Postmodern Studio（Alamy Stock Photo経由）
かつて危険だったNVIDIA Container Toolkitの脆弱性は、Kubernetesクラスターをコンテナエスケープから守る方法を示しています。
8月6日、ラスベガスのBlack Hat USAで、Wizの研究者たちがセッション「AIケージからの脱出：NVIDIAの脆弱性を使ったAIプロバイダーの攻略」を開催します。この講演は、同社が昨年9月に公開したCVE-2024-0132に関する研究を拡張したものです。これは、NVIDIA Container ToolkitのTOCTOU（チェック時と使用時のタイミング不一致）脆弱性であり、人気のオープンソースコンポーネントを利用するAIやクラウドプロバイダーでコンテナエスケープが可能になるものでした。
このコンポーネントは、多くの人気アプリケーションをコンテナ化するためにAIベンダーが広く利用しているツールであり、この脆弱性（CVSSスコアは10点中9点）は、悪用された場合、攻撃者が（環境によっては）AIモデルやデータセットなど、テナント間でアクセスできる可能性がありました。攻撃は、CVEページが指摘するように「コード実行、サービス拒否（DoS）、権限昇格、情報漏洩、データ改ざん」につながる可能性があります。
複数のコンテナランタイムが影響を受けましたが、特にKubernetesは脆弱でした。なぜなら、この脆弱性はNVIDIA GPU Operator（Kubernetes用のオペレーターで、Container Toolkitを自動的にデプロイ・管理する）にも影響していたからです。場合によっては、CVE-2024-0132を悪用することで、複数テナントで共有されているKubernetesクラスターの完全な侵害が可能となりました。
この問題や、CVE-2025-23359として追跡される関連する二次的なDoS脆弱性は、関係するベンダーによって緩和・修正されましたが、得られた教訓は今も生きています。
CVE-2024-0132の詳細な分析
Wizのセキュリティ研究者でありセッションの発表者であるHillai Ben-Sasson氏とAndres Riancho氏がDark Readingに語ったところによると、この脆弱性は簡単に悪用できました。Riancho氏によれば、ベンダーによっては、コンテナ化されたアプリケーション内から特別に細工した悪意のあるイメージを作成し、それを使ってホストシステム全体をマウントすることで、わずか1～2時間で脆弱性を突くことができたそうです。
Wizが2月に発表した技術的な詳細解説によると、「この脆弱性により、悪意ある攻撃者はホストのルートファイルシステムをコンテナ内にマウントでき、ホストのすべてのファイルに無制限にアクセスできます。さらに、ホストのコンテナランタイムのUnixソケットにアクセスできれば、攻撃者は特権コンテナを起動し、ホスト全体を完全に侵害することが可能です。」
CVE-2024-0132に関するこれまでの分析と比較して、Black Hatのセッションでは、Wizがこの脆弱性をテストした2つのケーススタディ（AIソフトウェア開発ベンダーのReplicateとクラウドインフラプロバイダーのDigitalOcean）について深く掘り下げます。
これらのケーススタディを通じて、Ben-Sasson氏、Riancho氏、そしてWizの研究者Ronen Shustin氏は、攻撃の仕組みや、攻撃者の横移動や機密データへのアクセスを防ぐための小さなセキュリティガードレールの効果について解説します。
「実際に有名なクラウドプロバイダーを同じ脆弱性でハッキングできた事例をいくつか紹介します。それぞれのケースがどのように異なり、何を達成できたのか、そして自分たちの環境に活かせる教訓は何かを共有します」とRiancho氏は語ります。
防御側ができること
現在、防御側にとってより重要なのは、Ben-Sasson氏とRiancho氏が強調する、Kubernetes特有の3つの小さな設定変更です。Riancho氏の言葉を借りれば、これらは「ターゲット環境に侵入しようとする者にとって最も厄介なセキュリティコントロール」となります。これらのコントロールがコンテナ化された環境にあれば、攻撃者や攻撃的なセキュリティ研究者が大きな影響を与えることはできません。
まず、防御側はUser Namespacesを活用すべきです。これはまだベータ段階の新機能ですが、コンテナをホストとは異なるユーザーで実行できるようにし、コンテナの権限を制限し、コンテナとホストの間にもう一つの分離層を追加します。
2つ目の変更は、Network Policiesを利用することです。これはアプリケーションの実行に必須ではありませんが、環境全体をより安全にします。これにより、クラスター内のトラフィックフローのルールを設定し、ポッドがどのネットワークエンティティと通信できるかを決定できます。
最後に、各Kubelet（Kubernetesの各ノードで動作するエージェント）の権限が十分に制限されていることを確認すべきです。
「各Kubeletには一連の認証情報があります。これらの認証情報はKube APIに接続する権限を持っており、場合によっては権限が過剰で、より多くの機能を実行できたり、サービス全体を乗っ取ることができる場合がありました」とRiancho氏は言います。「Kubeletに与える権限を制限することで、Kubernetesクラスター内での権限昇格の可能性を抑えることができます。」
Ben-Sasson氏の言葉を借りれば、「マクロな視点で言えば、強固でかつ互いに異なる複数のバリアを持つことが重要です。最初の防御が突破されても、残りのバリアを突破するのは依然として困難になるのです。」