概要

Cloudflareは、同社のコンテナ実行環境「Containers」（および未信頼コードやAIエージェントを実行する「Sandboxes」）において、削除済みコンテナが使用していたディスクブロックが別テナントのコンテナから読み取れる脆弱性を修正したと発表した。原因は、ストレージ層で採用しているLinuxのdm-thin（device mapper thin provisioning）のプール設定に含まれていた「skip_block_zeroing」オプションで、これが有効になっていたため新規に割り当てられる64KiB単位のディスクブロックが消去されず、前の利用者のデータがそのまま残存する状態になっていた。セキュリティ企業Accomplishの研究者Oren Yomtovが9月4日にバグバウンティ経由で報告し、Cloudflareは同日中に修正をマージ、9月19日までに全ホストでの是正作業を完了させたとしている。

脆弱性の技術的詳細

dm-thinはブロックを64KiB単位で割り当てるが、コンテナが実際に書き込むデータはそれより小さいことが多い。研究者のPoC（概念実証）は、この差分を突く形で成立した。ext4ファイルシステムの空き領域のうち64KiB境界に対応する箇所を特定し、そこにわずか4KiBのファイルを書き込むと、新規ブロック割り当てがトリガーされる。しかしskip_block_zeroing設定下では、書き込んだ4KiB分だけが上書きされ、残りの60KiBには直前の所有者のデータがそのまま残る。これをraw-device（生デバイス）レベルで読み取ることで、他テナントの残存データを回収できた。

研究者はext4のメタデータチェックサムを利用して、自分のファイルシステムに属さないディレクトリブロックを識別する手法を確立し、実環境での影響を検証した。その結果、6つの本番環境で2,700個の外部ディレクトリiノードを検出し、24回の試行のうち18回、また4大陸に分散する22の基盤ノードのうち20ノードで残存データの観測に成功した。回収されたデータには、ディレクトリ構造だけでなく、構造的に完全なSQLiteデータベースのページも含まれていたという。

対応と影響評価

Cloudflareの対応は段階的に行われた。まずskip_block_zeroing設定をフリート全体（全サーバー群）から削除し、新規に割り当てられるストレージブロックのゼロクリアを有効化した。続いて、既存の稼働中コンテナディスクと、事前キャッシュされていたOCIイメージレイヤーを廃棄し、オフピーク時間帯にホストVMを再起動してイメージキャッシュを一掃した。9月4日15:26 UTCの報告からランタイム修正のマージまでは6時間程度、全ホストでのキャッシュスナップショット削除完了までは9月19日15:03 UTCまでを要した。研究者による独立した再検証でも、修正後はPoCが機能しなくなったことが確認されている。

Cloudflareはディスクi/oのテレメトリを精査した結果、この攻撃経路を通じた活動としては研究者自身とCloudflareエンジニアによる認可済みテストのみが検出され、第三者による悪用の痕跡は見つかっていないとしている。ただし、影響範囲にはAIエージェントなど未信頼コードを実行する用途で使われるSandboxesも含まれており、マルチテナント環境でのストレージ再利用が持つリスクの大きさを改めて示す事例となった。ゼロクリアを前提としないthin provisioning設定は性能上のメリットがある一方、テナント分離が要求される環境では見落としやすい落とし穴であり、他のクラウドプロバイダーやコンテナ基盤の運用者にとっても設定点検の教訓となりそうだ。