CloudflareがリモートSpectre攻撃に成功、Workersから機密情報を最大12bit/秒で読み出す

親愛なる読者の皆さまへ。ご存じの通り価格高騰などの悪影響でサーバー運営がとても苦しい状態です。回線や台数を整理し見直せる部分は全て見直しましたが、やはりまだ危険水域です。このままだと1ページを10分割ぐらいして無理矢理PVを増やさざるを得なくなってしまいます。そこで、GIGAZINEの物理的なサーバーたちを、たった1円でも良いので親愛なる読者の皆さまに支援してもらえればとっても助かります！今すぐ寄付は上のボタンから！ ・ これまでGIGAZINEを支援してくれたメンバーのリスト

Cloudflareが本番環境のCloudflare WorkersでリモートSpectre攻撃を再現し、別のWorkerに保存したJWTトークンを最大12bit/秒、99％を超える精度で読み出すことに成功しました。実験はCloudflare側が管理する攻撃用Workerと被害者役のWorkerを対象にしたもので、研究で使われた攻撃手法はすでに対策済みとのことです。 A revisit of remote Spectre attacks on Cloudflare Workers | Cloudflare Blog https://blog.cloudflare.com/revisiting-spectre-attacks-on-workers/ Remote-Timer-as-a-Service: Efficient Microarchitectural Leakage in the Cloud with Remote Timers (PDFファイル) https://arxiv.org/pdf/2608.17043 Cloudflare Workersは利用者が用意したJavaScriptなどのコードをCloudflareのエッジサーバーで実行できるサービスです。一般的なサーバーでは利用者ごとにOSのプロセスを分ける方法がありますが、Workersでは起動時間や処理負荷を抑えるためJavaScriptエンジン「V8」のV8 isolateを利用して、多数の利用者を同じOSプロセス内で分離しています。各Workerには個別のJavaScript用メモリ領域が割り当てられるものの、複数の利用者が同じプロセスを共有するためCPU内部の動作を利用した攻撃への対策が重要になります。

SpectreはCPUの「投機的実行」を悪用する攻撃です。CPUは処理を高速化するため、条件分岐の行き先が確定する前に分岐先を予測して先の処理を始める場合があります。予測が外れれば処理結果は破棄されますが、CPUキャッシュなどにはわずかな痕跡が残る可能性があります。攻撃者はメモリへのアクセス時間の違いを測定し、本来なら読み出せないデータを推測するというわけです。 ただしSpectreでキャッシュのわずかな速度差を調べるには高精度な時計が必要です。Cloudflareは対策としてCPU処理中はWorkers内の時刻が実質的に進まないようにし、マルチスレッドや共有メモリも利用できないようにしたほか、2021年には怪しいCPU動作を検知したWorkerを別プロセスへ移す「Dynamic Process Isolation(DyPrIs)」を本番環境に導入しました。2021年に「Workers内部に高精度な時計がなくてもネットワークの向こう側に時計を置けばいい」という発想のもと、WebSocket経由で外部の高精度な時刻を利用する「リモートタイマー」を使った攻撃の研究が行われましたが、読み出し速度はタイマー役を同じマシン上に置くなど理想的な条件でも1時間当たり120bitにとどまっていました。

キャッシュヒットとキャッシュミスの時間差は数ナノ秒程度しかない一方、リモートタイマーにはネットワーク通信による大きな遅延の揺らぎが含まれるため、そのままでは両者を見分けるのが困難です。そこで研究チームはL1キャッシュから追い出すデータを決める「Pseudo Least Recently Used(PLRU)」と呼ばれる仕組みを利用。1回の小さな速度差を繰り返し増幅し、ネットワーク越しでも判別できる大きさに変換しました。少数の測定でもミリ秒未満の違いを扱える程度まで精度を高められたとのことです。 下図は増幅したキャッシュヒットとキャッシュミスの測定結果。上段がネットワーク越しのタイマーによる測定、下段は内部の高精度タイマーで測定した基準値です。下段ではキャッシュの初期状態によってPLRU増幅後の処理時間が明確に分かれています。上段ではネットワークの揺らぎによって分布が重なっていますが、中央値には差があり、複数回の測定によって統計的にキャッシュヒットとキャッシュミスを判別できます。

もう1つの課題が攻撃側と被害側のWorkerを同じ実行環境に置き、攻撃に必要な状態を長時間維持することでした。研究チームは長時間動作する処理を扱えるCloudflareの「Durable Objects」とWebSocketを組み合わせました。処理の途中で定期的に制御を戻すことで、1つのisolateを5時間から20時間以上維持できたとCloudflareは説明しています。 キャッシュから特定のデータを追い出す作業についても工夫が加えられました。従来のように目的のキャッシュ位置を正確に探すのではなく、キャッシュ容量よりはるかに大きなデータ領域を確保して毎回新しい場所を選択します。選んだ場所がすでにキャッシュから追い出されている可能性を高くすることで、遠隔タイマーを使った面倒なキャッシュ位置の探索を避けました。 研究チームは複数の手法を組み合わせ、Cloudflare Workersの本番環境で一連の攻撃を実行しました。攻撃側のWorkerからメモリを読み出した後、自分たちが管理する被害者役のWorkerにあらかじめ秘密情報を配置し、別のWorkerから読み出せることを確認しています。 最終的には被害者役のWorkerにJWTトークンを置き、1bitずつ内容を読み出すことに成功。複数回の測定結果から多数決やしきい値を使って0と1を判定したところ、以前の毎時120bitと比べると最大で約360倍の読み出し速度である12bit/秒を本番環境で達成し、精度も99％を超えていたとのこと。速度をさらに上げることも可能ですが、精度は低下すると述べられています。 下図はJWTトークンの先頭1バイトを1bitずつ判定した結果。測定を繰り返し、0と1のどちらに該当するかを推測しています。

一方で従来のDyPrIsが攻撃を止められなかった理由も判明しました。DyPrIsはCPUのハードウェア性能カウンターを監視し、Spectre攻撃らしいWorkerを検知すると別のプロセスへ隔離する仕組みです。しかしDyPrIsはWorkerの1回の実行が終了してから隔離する仕組みだったため、WebSocketを利用して1回の実行を長時間続ければ、隔離が始まるより先に情報を読み出せていたとのこと。またDyPrIsは分岐予測の失敗回数をiTLBへのアクセス回数と比較して攻撃を判定していましたが、大量のWebSocket通信によってiTLBアクセスが増えるとSpectre特有の動作が目立ちにくくなったとのことです。 Cloudflareは研究結果を受け、DyPrIsについて長時間動作するWorkerや入出力の多い処理を前提に検知方法を改良。さらにV8 Sandboxの導入により今回使われた64bitポインターを利用する攻撃手法をそのままでは動作しないようにしたほか、2025年9月にはCPUの「Memory