Cloudflare Containersでディスク未初期化によるクロステナント漏えい、他社のSQLiteデータが読み取り可能だった

概要

Cloudflareは、コンテナプラットフォーム「Containers」においてストレージ層の分離が破られ、他テナントのデータを読み取れる脆弱性を公表した。原因はLinuxのdevice mapper thin provisioningでskip_block_zeroing設定が有効になっていたことで、新規割り当てされたディスクブロックがゼロ初期化されないまま再利用されていた。コンテナが未マップ領域に4KiBのブロックを書き込むと、システムは共有プールから64KiBの物理ブロックを割り当てるが、実際に書き込まれるのはそのうちの一部のみで、残り最大60KiBには前のテナントが残したデータがそのまま残存し、生のディスク読み取りを通じて取得できる状態だった。

発見から修正までの経緯

脆弱性はバグバウンティを通じて、セキュリティ研究者のOren Yomtov氏によって9月4日15:26 UTCに報告された。Cloudflareは同日23:15 UTCにはランタイム側の修正デプロイを開始し、9月7日までにロールアウトを完了。さらにディスクの退役、ホストのドレイン、キャッシュのクリアなどを含む全面的な対応を9月19日までに終えたとしている。研究者には9月14日に報奨金が支払われた。報告から初動対応までが数時間という速さだったことがタイムラインから分かる。

漏えいの範囲と実際に取得できたデータ

今回の調査では、グローバル24か所のプロダクション環境のうち18か所で、他テナントに属するディレクトリ構造やデータベースページ、さらには完全なSQLiteデータベースまで復元できたことが確認されている。検証可能だった5,614件のディレクトリブロックはすべて他者由来のものであり、2,700件の異なる外部ディレクトリinodeが識別されたという。これは単なる理論上の脆弱性ではなく、実際に広範囲のテナントデータが影響を受け得る状態にあったことを示している。

影響の限定要因とCloudflareの説明

一方でCloudflareは、攻撃者が特定の被害者や狙ったワークロードのデータを選んで取得することはできず、残存データが実際に存在するかどうかも保証されていなかったと説明している。また、悪用された証拠は確認されていないとしている。ただし、この種の「テナント分離は保証されている」という前提が、ストレージ層での独立した検証なしには成立しないことを今回のインシデントは示した。業界の反応としても、分離を主張するなら各インフラ層で明示的なzero-on-allocateの検証が不可欠であり、アーキテクチャ上の想定だけに依拠すべきではないという教訓が指摘されている。