CVE-2022-23648：ContainerdのCRI プラグインによりコンテナエスケープの可能性 #aqua #セキュリティ #cve202223648 #ccontainerd
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年3月28日に公開された「 CVE-2022-23648 in Containerd's CRI Plugin Could Allow for Container Breakout 」の日本語翻訳です。
CVE-2022-23648：ContainerdのCRI プラグインによりコンテナエスケープの可能性
最近発見された containerd の脆弱性により、クラスター内でカスタムイメージを実行できる攻撃者は、基盤となるノードに侵入し、場合によってはクラスター管理者レベルまで権限を昇格させることができます。
この脆弱性は、いくつかの理由で興味深いものです。まず、この脆弱性は Kubernetes マニフェストではなく、コンテナイメージに内包されているため、Infrastructure-as-Code(IaC)や Admission Controll のソリューションで発見するのが難しいという点です。第二に、一般的なコンテナイメージコマンドを使用しているため、マルウェアスキャンエージェントでは容易に検出できないことです。
この脆弱性の詳細と可能な緩和策について話すことに加えて、これらの問題を強調する Kubernetes セキュリティコミュニティの役割に注目することが重要です。この問題を発見した研究者からの情報に気づいた後、コミュニティの複数のメンバーが、この問題を再現し、起こりうる影響と可能な緩和策を理解することに取り組みました。これらの議論は、一般的に Kubernetes Slack の #Kubernetes-Security チャンネルと #SIG-Security チャンネルで見ることができます。
技術的詳細
この問題は2021年11月に発見・報告され、2022年3月2日に containerd 用のパッチがリリースされています。原因は Kubernetes クラスターと containerd の間のインタフェースとなる container runtime interface(CRI)プラグインにあります。問題は、コンテナイメージにホスト上のパスを参照するボリューム(例：/../.../.../.../var/lib/kubelet/pki/)を指定すると、起動時にホスト上の任意のファイルが実行中のコンテナにコピーされてしまうことでした。
これにより、カスタムイメージを作成できる攻撃者は、基盤となるホストから認証情報などを取得できるようになり、そのクラスターノードで特権に昇格させることが可能になります(おそらくクラスター全体でも昇格させることができます)。
この問題を悪用する基本的なコンテナの例を以下に示します。
|
FROM registry.access.redhat.com/ubi8/ubi |
このイメージをビルドしてからクラスターにデプロイすると、以下の動画に示されているように、kubelet の秘密鍵が実行中のコンテナにコピーされます。
この例では、これらの認証情報を使用して、Kubernetes API を介して、kubelet 自体の権限でアクションを実行できます。
さらに、この例のファイルと、クラスター内の権限昇格を表示するために使用できるより高度なオプションを含む GitHub リポジトリがあります。
これは、攻撃者が関心を持つホスト上の他のディレクトリを指すようにボリュームステートメントを変更することで、この攻撃を利用する方法の一例に過ぎません。
この脆弱性は、containerd の CRI コンポーネントに存在するため、コンテナランタイムとして Docker を使用しているクラスターでは、containerd の CRI の代わりに Dockershim を使用すると、悪用される可能性は低くなります。
検知と緩和
この問題の使用方法によっては、検知が難しくなる可能性があります。コピー処理は、コンテナ内で実行されているユーザではなく、containerd 自身によって行われるため、検知はクラスターノードのファイルシステム上の機密性の高い場所を監視するくらいしか無いかもしれません。例えば、上記の基本的な例では、kubelet の秘密鍵ファイルへのアクセスがあったため、これを監視対象とする必要があります。
緩和と同様に、パッチが適用されたバージョンをすべてのクラスターノードにデプロイすることが正しいアプローチです。また、信頼できるイメージのみがクラスターへデプロイされるようにすることも、この問題に対する重要なセキュリティ管理方法です。
これらの対策が現実的でない場合、または一時的な修正として、Admission Controller を使用して、デプロイされているイメージを確認できます。この方法は、使用する Admission Controll ソフトウェアが、その検証プロセスの一部として外部データを参照できることに依存しますが、Kyverno と OPA を使用することで可能となります。具体的には、Kyverno はボリュームステートメントを持つコンテナイメージをブロックするためのポリシーを備えています。この機能が必要な場合は、完全にブロックするのが安全な方法です。
まとめ
これは、2022年にいくつか出てきたコンテナエスケープの脆弱性の1つです。これらの脆弱性は、一般的な Kubernetes スタックのいくつかのレイヤーに影響を及ぼしています。それぞれのケースで、ベクターと可能な緩和策は多少異なりますが、クラスター運用者が注目すべき共通のテーマがいくつかあります。
まず、これらの脆弱性は、すべてのクラスターノードで定期的にパッチを適用することの重要性を強調しています。これは、リスクを最小限に抑え、必要なとき迅速かつ安全にパッチを適用するため、頻繁に実践される慣習があるべきです。
もう1つの重要なポイントは、Kubernetes 環境には徹底的な防御戦略が必要だということです。単一の予防的コントロールではクラスターを安全に保つことはできないため、潜在的な弱点を考慮し、予防的コントロールと防御的コントロールの両方のレイヤーセットが絶対に必要です。
