Dirty Pipe Linuxの脆弱性：コンテナイメージのファイル上書き #aqua #セキュリティ #コンテナ #dirtypipe #linux #cve20220847
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年3月8日に公開された「 Dirty Pipe Linux Vulnerability: Overwriting Files in Container Images 」の日本語翻訳です。
Dirty Pipe Linuxの脆弱性：コンテナイメージのファイル上書き
今週 Linux カーネルにおける新たな CVE が公開されました。CVE-2022-0847 は、別名「Dirty Pipe」と呼ばれ、Linux システム上のユーザが、読み取りはできるが書き込みはできないはずのファイルの内容を上書きできる脆弱性です。この脆弱性を、Docker などのコンテナ化ソフトウェアを使用しているホストの観点から見ると、ホスト上のコンテナイメージのファイルを、コンテナ内部から変更可能となります(一般的には不可能なはずです)。
これにより、攻撃者は、共有イメージに対して実行されているコンテナを効果的に変更したり、ホスト上のイメージを汚染して、新しいコンテナが変更されたファイルを受け取ることが可能になります。
この問題を軽減するために、影響を受けるシステム(Linux カーネル 5.8 以上を実行しているシステム)には、直ちにパッチが適用されるべきです。
技術的な詳細
この脆弱性を公開したページには詳細と詳細な背景が書かれていますので、ここではコンテナの観点からの影響に焦点を当てます。
最新のコンテナ化では、Overlay ファイルシステムの使用が不可欠です。Overlay ファイルシステムでは、共有の読み取り専用イメージを使用して、実行中のコンテナを作成します。コンテナ内のユーザが基礎となるイメージのファイルを変更する場合、元のファイルはそのコンテナ専用の新しい場所にコピーされ、そこで変更が適用されるはずです。元のファイルは、変更されないままでなければなりません。
Max Kellermann 氏のブログで提供されているエクスプロイトを使用して、基盤システム上のファイルを変更し、何が起こるかを確認できます。
以下環境は、Docker 20.10.10 を実行している Ubuntu 21.04 システムを使用しており、現在ローカルにダウンロードされているコンテナイメージはない状態です。
まず、ubuntu:21.04 イメージをベースにしたコンテナを起動し、Docker Hub から新たなイメージのコピーを取得します。この exploit はどのイメージでも動作するはずですが、このイメージはクリーンなイメージがベースとなっています。
次に、元の脆弱性公開ブログにあるコードをコンパイルしたエクスプロイトコードをコピーし、基盤となるイメージからファイルを変更しようとします。デモとして、/etc/shells を使用します。
最初に、このファイルには予想通りに次のような内容が含まれていることがわかります。
次に、エクスプロイトを実行し、ファイルの先頭に「Hello World」という文字列を追加することを試みます。そのコンテナ内のファイルが、変更されたことがわかります。これは想定内の挙動です。なぜならば、この時点ではそのコンテナの root ユーザで実行されているからです。
ここでホストに戻り、同じイメージをベースにした新しいコンテナを起動します。新しいコンテナには、変更されたファイルは「ない」はずです。
ですが、ここで変更されたファイルをはっきりと確認することができるので、エクスプロイトが予想通り動作していることがわかります。
このエクスプロイトは、既存のコンテナにも影響を与えることができます。たとえば、共有イメージを使用する 10 個の nginx コンテナがあるホストで、攻撃者が 1 つの nginx.conf ファイルを変更した場合、ベースとなるイメージのファイルをまだ使用していれば、他のコンテナのファイルも即座に変更されます。
また、ホストからボリュームが読み取り専用でマウントされている場合も、この脆弱性を利用すれば、その制限を無効化できます。
影響範囲と軽減策
この問題がどの程度深刻であるかは、お客様の環境のアーキテクチャに依存します。この問題を悪用するには、攻撃者はホスト上の単一のコンテナにアクセスする必要があります。そこにアクセス権があり、カーネルバージョンが今回の脆弱性を含むものであれば、コンテナの作成に使用されたイメージからアクセスできるファイル、または基盤となるホストから読み取り専用でマウントされているファイルを変更できます。
この問題は、共有イメージファイルを使用して実行されている多数のコンテナがあり、信頼できないユーザが個々のコンテナにアクセスできますが、基盤となるホスト上のファイルを変更できないはずの場合に、最も大きな影響を及ぼすと思われます。
Linux カーネルの脆弱性と同様に、定期的にアップグレードを行い、アップグレード後にホストを再起動して、パッチが有効になっていることの確認が最善のアドバイスとなります。
