Leaky Vessels: Docker および runc コンテナブレイクアウトの脆弱性 (2024 年 1 月)

Snyk のセキュリティ研究者 Rory McNamara は、Snyk Security Labs チームとともに、コンテナのエスケープを可能にする「Leaky Vessels」と呼ばれる 4 つの脆弱性がコアコンテナインフラストラクチャコンポーネントにあることを特定しました。攻撃者がこれらのコンテナエスケープを使用すると、基盤となるホストオペレーティングシステムにコンテナ内から不正にアクセスできる可能性があります。攻撃者は基盤となるホストオペレーティングシステムにアクセスすると、機密データ (認証情報、顧客情報など) を含むシステム上のあらゆるデータにアクセスして、さらなる攻撃を開始する可能性があります。Security Labs チームは、これらの脆弱性を発見して検証した後、責任ある開示を行うためのプロセスを開始し、まず Docker に通知しました。Docker は確認後、脆弱性の 1 つをオープンソースの runc セキュリティグループに転送しました。開示のタイムラインは以下のとおりです。 

これらの脆弱性は、広く使用されている下位のコンテナエンジンコンポーネントやコンテナビルドツールに影響を及ぼすため、コンテナのビルドベンダーとランタイムベンダー (Docker、Kubernetes ベンダー、クラウドコンテナサービス、オープンソースコミュニティなど) からのアップデートの有無を確認することを強くお勧めします。プロバイダーから修正プログラムがリリースされたらすぐに、コンテナエンジンとコンテナビルドツールを実行しているシステムをアップグレードする必要があります。

脆弱性について

2024 年 1 月 31 日、runc (Linux 上でコンテナを生成および実行するための CLI ツール) のメンテナーは、WORKDIR コマンドを中心とした操作順序コンテナブレイクアウトを可能にする脆弱性 (CVE-2024-21626) を発表しました。この脆弱性が悪用されると、基盤となるホストオペレーティングシステムにコンテナがエスケープする可能性があります。この問題は、悪意のあるイメージを実行するか、悪意のある Dockerfile またはアップストリームイメージを使用してコンテナイメージをビルドする (FROM を使用する場合) ことによって発生する可能性があります。メンテナーによると、パッチ適用済みバージョンの runc 1.1.12 は、2024 年 1 月 31 日午後 3 時 (EST) 頃にリリースされました。

この脆弱性の詳細については、runc の脆弱性自体の概要を説明したこちらの概要ブログをご確認ください。Rory と Snyk Labs チームは、これ以外にも 3 つのコンテナエスケープ脆弱性 (合計 4 つ) を特定しました。以下のリストは、各脆弱性とそれに対応する CVE および概要ブログへのリンクを示しています。

• CVE-2024-21626: runc process.cwd と漏洩した fds コンテナブレイクアウト

• CVE-2024-23651: BuildKit マウントキャッシュ競合

• CVE-2024-23653: BuildKit GRPC SecurityMode 特権チェック

• CVE-2024-23652: BuildKit ビルド時コンテナ破棄中の任意ファイルの削除

これらの脆弱性の検出に役立つツールを Snyk が提供

これらの脆弱性は、コンテナイメージではなく、基盤となるコンテナインフラストラクチャとビルドツールに影響を与えます。Snyk Container は、コンテナイメージの脆弱性を排除する開発者を支援するように設計されているため、これらの脆弱性はスコープ外であり、Snyk 製品が現在評価対象としているものではありません。ただし Snyk は、エクスプロイトの試みを検出するためのリファレンス実装として機能する 2 つのオープンソースツールを開発しました。これらのツールは Snyk サポートの対象にはならず、あくまでもコミュニティ向けのサンプルとして提供されていることに注意してください。 

ランタイムエクスプロイト検出 (leaky-vessels-runtime-detector)

Snyk に新設された Helios チームは、この脆弱性に対するランタイム検出ツールをビルドしました。このツールは、このツールは Apache-2.0 ライセンスに基づいてリリースされたもので、「leaky-vessels-runtime-detector」にあります。Apache-2.0 ライセンスに基づいてリリースされたこのスタンドアロンツールは、実行時に脆弱性を検出するためのリファレンス実装を提供します。このツールは、eBPF フックをカーネルレベルおよびユーザーレベルの機能およびパッケージディテクターに関連付けます。これにより、エクスプロイトの試みの可能性を示すパターンとの一致が確認された場合に、コンテナビルドの呼び出しとコンテナの実行を報告できるようになります。Linux ディストリビューションまたはバージョンのすべてが eBPF をサポートしているわけではなく、顧客が eBPF をクラウドサービスプロバイダーで利用できる可能性は低いことに注意してください。

静的コンテナコマンド検出 (leaky-vessels-static-detector)

2 番目のツールは、同じく Apache-2.0 ライセンスに基づいてリリースされた静的分析プログラムの leaky-vessels-static-detector です。このツールは、Dockerfile とイメージレイヤーをスキャンして、脆弱性を悪用しようとしていると考えられるコマンドを検出し、疑わしいコマンドが検出されたかどうかを示す JSON 形式の出力を提供します。コンテナビルドコマンドの正当な使用ではない、実際のエクスプロイトであるかどうかを判断するには、各ヒットを手動で検査する必要があることに注意することが重要です。

Snyk は、潜在的なエクスプロイトの試みを検出するためのリファレンス実装をコミュニティに提供するために、これら 2 つのツールをオープンソースとしてリリースしています。ランタイムツールは、静的ツールよりも高いレベルの信頼性を結果にもたらす傾向があります。ただし、エクスプロイトとビルドコマンドの性質を考えると、どちらのツールでもある程度の見逃しと誤検知が生じる可能性があります。コミュニティは、これらのツールをサンプルとして使用して独自のツールを作成したり、自分の環境でツールを実行したりできます。これらのツールは脆弱性を修正したり、エクスプロイトをブロックしたりするものではありませんが、リスク領域の特定に役立つという点を覚えておいてください。最も賢明な方法は、パッチが利用可能になったときに、影響を受けているコンテナオーケストレーションプラットフォームをアップデートすることです。 

アクティブなエクスプロイトの有無

Snyk チームは、最も頻繁に使用されているイメージに基づいて、パブリックレジストリからの Dockerfile のアドホックチェックを実行しました。網羅的ではありませんが、この調査では、これらの脆弱性が悪用されたことを示す証拠は見つかりませんでした。パッチが利用可能になってデプロイされるまで、ご自分の環境を継続的に監視し、コンテナをチェックすることをお勧めします。問題の性質を踏まえ、Snyk は前述した 2 つのオープンソースツールを作成しました。1 つは、実行時に脆弱性からのアクションの検出を実証する動的ツールで、もう 1 つは、イメージと Dockerfile をスキャンすることで潜在的なエクスプロイトの指標として機能する静的ツールです。

対策準備

対策はインフラストラクチャレベルとコードツールレベルで行う必要があります。該当する場合は、コンテナのビルドおよびオーケストレーションシステムのプロバイダーまたはベンダーからの発表やリリースを探します。  Docker デーモンと Kubernetes デプロイメントのアップデートに加え、CI/CD パイプライン、ビルドサーバー、開発者のワークステーションで使用しているコンテナビルドツールのアップデートも必要になる場合があります。Snyk がビルドしたツールなどを使用して既存のコンテナをスクリーニングし、オーケストレーションノードやビルドインフラストラクチャがすでに影響を受けているかどうかを判断することも重要です。

以下に、広く使用されているツールやサービスから収集したアップデートをいくつかご紹介します。

脆弱性開示の流れ

脆弱性のタイムラインは、特に複数のエンティティが関係している場合に複雑になる可能性があります。修正プログラムが利用可能になる前に悪意のある攻撃者に脆弱性が知られることのないよう、脆弱性の開示は責任を持って行うことが非常に重要です。 

このケースでは、脆弱性が最初に検出されたのは 2 か月前でした。その時点で、Snyk は責任ある脆弱性開示のプロセスを開始しました。以下は、開示のプロセスにおける主要なマイルストーンのタイムラインを示したものです。

脆弱性開示プロセスの各ステップには、組織内および組織間のコラボレーションが含まれ、営利組織だけでなく、多くの場合、コミュニティのさまざまな部門で構成されるコンポーネント保守チームも含まれます。

Snyk の Security Labs チームについて

Snyk の Security Labs チームはこれまで、さまざまなエコシステムにわたる主要パッケージに含まれる、3,200 件を超える脆弱性の責任ある公開に貢献してきました。あらゆる脆弱性に責任を持って効率的に対処できるよう、当チームはオープンソースパッケージのメンテナーと緊密に連携しています。当チームのセキュリティ専門知識は、Snyk がセキュリティ業界の多くの大手企業から信頼されている理由の 1 つです。脆弱性と考えられるものを発見したものの、その責任ある開示方法がわからない場合は、こちらのフォームにご記入ください。Snyk のチームがお手伝いいたします。

Snyk 自身の脆弱性事例

Snyk が自社環境の脆弱性にどのように対処しているかについては、Snyk トラストポータルをご覧ください。

まとめ

このブログは詳細情報を入手し次第、更新する予定です。また、2 月 6 日 (火) 午前 11 時 (東部時間) には、「Leaky Vessels コンテナブレイクアウトの脆弱性 - 知っておくべきこと」に関するウェビナーを開催いたします。Snyk のテクニカルエキスパートからは、Leaky Vessels の脆弱性の 1 つとその原因、悪用の手法、そして最も重要なことに、アップグレードと監視を通じて脆弱性を軽減する方法について、詳細な技術的レビューを提供いたします。

脆弱性についてご質問がある場合は、お気軽にお問い合わせください。オープンソースツールの場合は、各ツール (dynamic-detector および static-detector) で GitHub チケットを作成するか、Snyk コミュニティ Discord からご連絡ください。 

Leaky Vessels について詳しくは、以下の資料を参照してください。

• Leaky Vessels — runc 脆弱性の解説 (YouTube)

• Leaky Vessels の詳細: syscall 単位での Docker からのエスケープ (ブログ)

• ハンズオンレッスン: runc process.cwd コンテナブレイクアウトの脆弱性 (Snyk Learn)

この記事は情報提供のみを目的として提供されています。Snyk は、この情報のいかなる誤りや欠落、あるいは情報の使用から得られた結果についても責任を負いません。

変更ログ

• 2024 年 1 月 31 日午後 3 時 (東部標準時): 初期リリース

• 2024 年 1 月 31 日午後 6 時 (東部標準時): CVE URL を追加。AWS、containerd、GCP、Docker、Ubuntu からの最新情報を追加

• 2024 年 2 月 7 日午後 1 時 (東部標準時): YouTube ビデオと詳細リンクを「まとめ」セクションに追加

• 2024 年 2 月 8 日午前 10 時 (東部標準時): Snyk Learn レッスンを「まとめ」セクションに追加