Cloudflare のコンテナ分離が顧客間で漏れていた。最も影響が重いのは AI エージェント向けに売られている製品だ

Cloudflare は9月24日、Containers プラットフォームの脆弱性に関する事後報告を公開した。ある顧客のワークロードが、別の顧客のワークロードが残したディスクデータを読める状態になっていたという問題だ。同社は、この問題はすでに完全に修正済みであり、過去のディスク I/O テレメトリを精査した結果、報告した研究者と自社エンジニア以外に利用した形跡はなかったとしている。開示は異例なほど詳細で、対応も異例なほど速かった。しかし、それによって脆弱性の性質が変わるわけではない。この製品がまさに売りにしている境界そのものが破れていたのである。

何が起きたのか

Containers と、その上に構築された Sandboxes は、顧客のワークロードをシンプロビジョニングのストレージに支えられた共有ホスト上で動かしている。ディスク領域はワークロードの書き込みに応じて 64 KiB のブロック単位で割り当てられ、ワークロードが破棄されると共有プールへ返される。Cloudflare は、ブロックを次の利用者に渡す前にゼロ埋めするというストレージ層の既定動作を無効にしていた。dm-thin プールの skip_block_zeroing という設定で、性能上の判断によるものだ。その結果、ブロックは前の利用者が書き込んだ内容を保持したまま、新しいコンテナに渡されうる状態になっていた。

これが生むのは、稼働中データへのアクセスではなく「残留データの露出」である。Cloudflare の説明は限界についても具体的だ。攻撃者は標的を選ぶことができず、稼働中のワークロードに接続されているディスクを読むこともできず、他社のデータを改変したり可用性に影響を与えたりすることもできない。戻ってくる可能性があったのは、そのホスト上でそのブロックを以前に占有していた誰かのファイルシステムのメタデータ、ディレクトリ構造、データベースのページ、そしてアプリケーションデータである。

どの程度の規模だったのか

Cloudflare の HackerOne プログラム経由で報告した Accomplish の Oren Yomtov 氏は、規模を具体的に示す計測結果を公表している。他テナントの残留データは、4大陸にまたがる24件のコンテナ配置のうち18件で、また22台の基盤マシンのうち20台で確認された。検査可能なディレクトリブロック 5,614 件のうち、他テナントに属する約 2,700 の異なるディレクトリ inode が特定され、構造的に完全な SQLite データベースも見つかっている。

これは不運な割り当てによって起きた狭いエッジケースではない。プラットフォームの通常動作そのものだ。

Sandboxes こそが居心地の悪い部分である理由

Containers はインフラである。その上で Cloudflare が売っているのが Sandboxes であり、ドキュメントはその用途を明確に述べている。大規模言語モデルが生成したコードの実行、そして「信頼できないコードを実行する必要のある AI エージェント、コードアシスタント、自律システム」である。

その作業の最中に、稼働中のエージェントがディスク上に何を残すかを考えてみてほしい。チェックアウトしたリポジトリ。.env ファイル。サブプロセスから読めるようにどこかへ書き出された短命の API トークン。エージェントが何をしていたかの記録を含む SQLite の状態。エージェントが役に立つために必要とする成果物の一群は、そっくりそのまま、再利用されるブロックに置き去りにされて最も困るものの一群と一致する。サンドボックスとは、信頼しないと決めたコードの周囲に引いた境界線である。製品の価値は、その境界が保たれることに全面的に依存している。

顧客に実際にできること

パッチという意味ではない。CVE も、移行すべきバージョンも、関与した顧客側の設定も存在しない。修正はサーバー側で行われ、すでに全機群へ展開済みだ。

本当の論点は認証情報であり、これは指示ではなく判断の問題になる。Cloudflare のテレメトリ精査が示しているのは、この特定の手法が他者に使われていなかったということだ。9月7日より前に Container や Sandbox 内に存在したいかなる秘密情報も見られていない、ということまでは示していないし、示しようもない。それらのワークロード内に長期有効な認証情報を置いていた組織は、ローテーションのコストと天秤にかけて判断すべきだろう。心もとない答えだが、それが残留データ露出という事象の性質である。被害側のログには、探すべきものが何も残らない。

評価すべき点と、その下にある取引

このタイムラインは声に出して言う価値がある。報告から本番環境での確認まで3時間19分。報告から修正のマージまで6時間。展開は同日中に始まっている。これほど速く報告を認めるベンダーは多くない。さらに、危険な挙動が見落としではなく意図的な性能設定であったと認めたうえで仕組みを公開したことは、開示の慣行が求める水準をはるかに超えている。

対応の良さは、より大きな論点を消しはしない。業界はこの2年、信頼できないコードの実行を顧客自身のマシンから共有のマルチテナント基盤へ移してきた。エージェントに、安く即座に動く場所が必要だからだ。この取引が買っているのは速度とコストであり、売り渡しているのは、分離があらゆる層で保たれているという前提である。誰も宣伝しないブロック割り当てのような地味な層も含めて、だ。今回それは、ストレージプール以外のすべての層で保たれていた。

ソース: Cloudflare Blog · The Hacker News · Cyber Security News · GBHackers · Cloudflare Sandbox SDK ドキュメント