Branch Privilege Injection：分岐予測器の競合状態を悪用
(comsec.ethz.ch)- Branch Privilege Injectionは、Intel CPUの分岐予測器における競合状態により、約6年間維持されてきたSpectre-BTI系のハードウェア防御を再び回避可能にする脆弱性
- 攻撃の核心は、分岐予測器の更新が命令フローと非同期に処理され、特定条件下では数十〜数百サイクル遅れて反映される場合がある点
- 権限遷移やIBPB実行中に遅延した更新が残っていると、その後誤ったセキュリティドメインに紐づけられ、eIBRSとIBPBのセキュリティ保証が破られる可能性がある
- 研究者らはUbuntu 24.04でデフォルトの緩和策をすべて有効にした状態で、Intel Raptor Lake第13世代から任意メモリを5.6KiB/sで漏えいさせるエンドツーエンド攻撃を実演
- Intelのマイクロコード更新は、Alder Lakeでの評価において脆弱性検出プリミティブをブロックし、最大2.7%のオーバーヘッドを示した
Branch Privilege Injectionが成立する条件
- Branch Privilege Injectionは、分岐ターゲットインジェクション攻撃、つまりSpectre-BTIの威力をIntel環境で再び可能にする攻撃
- Intelのハードウェア緩和策は約6年間この種の攻撃を防いできたが、今回の研究はIntel CPUの競合状態がその防御を揺るがし得ることを示している
- 攻撃は2つの観察に基づく
- Intelプロセッサの分岐予測器は命令フローと非同期に更新される
- 特定条件では更新が数十または数百サイクル遅延する
- 非同期更新自体は脆弱性ではなく機能である
- セキュリティ上重要な動作中に、分岐予測器と命令フローの間の同期が十分ではない
- ユーザーモードからカーネルへ、ゲストからハイパーバイザーへ遷移する間、更新がまだ進行中である可能性がある
- IBPB実行中にも進行中の更新が残っている可能性がある
- こうした更新が権限遷移後に到着すると、以前の権限ではなく新しい権限モードに紐づけられる
- Intelプロセッサの分岐予測器は命令フローと非同期に更新される
- この脆弱性の種類の名称はBranch Predictor Race Conditions
破られる緩和策と影響範囲
- eIBRSは、Intelが第9世代Coffee Lake Refresh以降のすべてのプロセッサに導入したSpectre-BTI緩和策
- 間接分岐予測を異なるセキュリティドメインごとに分離することが目的
- 各予測を生成されたドメインに紐づけ、以後は現在のドメインの予測だけを使うよう設計されている
- 権限遷移中に進行中の更新が新しいセキュリティドメインに紐づけられると、この関連付けを操作できる
- IBPBは、同じハードウェアセキュリティドメイン内でサンドボックスや互いに信頼しない仮想マシンを分離する際に使われるメカニズム
- すべての間接分岐予測を無効化する機能を提供する
- 進行中の更新はIBPBではフラッシュされないため、無効化後も分岐予測器に保存される可能性がある
- 影響範囲には世代やアーキテクチャによる差がある
- Intel第9世代Coffee Lake Refresh以降のすべてのプロセッサがBranch Privilege Injectionの影響を受ける
- IBPB回避予測は第7世代Kaby Lakeまでさかのぼって観測された
- 評価したAMDおよびARMシステムでは問題は見つからなかった
- 概念実証攻撃はLinux向けに作成されたが、根本問題はハードウェアにあるため、影響を受けるハードウェア上で動作するOSは影響を受ける
緩和策、性能コスト、公開資料
- 最新のOSとBIOSアップデートのインストールが推奨される
- Intelは影響を受けるプロセッサ向けのマイクロコード更新を開発し、研究者らはAlder Lakeでこれを評価した
- マイクロコード緩和策は脆弱性検出プリミティブをブロックする
- Alder Lakeで最大2.7%のオーバーヘッドを示した
- ソフトウェアによる代替緩和策も評価された
- Coffee Lake Refreshでは1.6%のオーバーヘッド
- Rocket Lakeでは8.3%のオーバーヘッド
- 詳細な技術内容は論文で確認できる
- Branch Privilege Injectionの論文はUSENIX Security 2025で発表予定で、Black Hat USA 2025での発表も予定されている
- 攻撃と実験のソースコードはgithubで公開されている
1件のコメント
Hacker Newsのコメント
研究チームのブログ記事: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
論文: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
攻撃の状況では、最終的にCPUメモリ全体の情報が不正な手に渡るのは時間の問題になる
良い記事。要するに 分岐予測器の更新 は、分岐命令がリタイアしたかなり後まで遅延されうるということ
そうでなければ分岐命令のリタイアにもっと時間がかかるはずなので、理にかなっている。ディスパッチを直列化する命令も、予測器状態への保留中の更新のためにパイプラインを停止させていないようで、これは「分岐命令結果のコミット」と「予測結果のコミット」をすでに分離しているため自然だ
権限変更命令も保留中の更新のためにパイプラインを止めないが、これは予測を作成したときとコミットするときの権限レベルが一貫していると保証できる場合にのみ妥当だ。そうでなければ、ある権限レベルのコードが作った予測が別の権限レベルで使われる状態にコミットされうる
おそらくパイプライン内では 現在の権限レベル が単一で明確な値ではないため、難しい問題なのかもしれない
Kaveh Razaviの名前を見るとうれしい。以前アムステルダムのVrije Universiteitで教えていて、Hardware Security の授業でこうした内容を深く扱っており、本当に素晴らしかった
公式の録画やノートがオンラインにあるのか気になる
これが今さっき公開された Training Solo 攻撃とどう関係しているのか知っている人いる？ https://www.vusec.net/projects/training-solo/
Training Soloはカーネルに入り権限レベルを変えた後、「自己学習」によって分岐が disclosure gadget 側へ誤予測されるようにし、メモリを漏えいさせる
Branch predictor race conditions は、学習済みの分岐予測器更新がまだ処理中の間にカーネルへ入り、その更新が誤った権限レベルに結び付けられるようにする。これを再び利用してカーネルの分岐を disclosure gadget に向け、メモリを漏えいさせる
CPUの 分岐予測器 が、バッファ境界とコードの権限レベルを確認するための情報をすぐ使えたなら、こうした問題ははるかに防ぎやすかったはず
だがCプログラマたちの冷たい手から
void*を取り上げ、ポインタに重要な情報を補強するまでは、そんなことは起きそうにない望むことを実現するには、すべてのロード/ストアが境界情報を保持する種の「拡張アドレス」を経由するハードウェアアーキテクチャが必要になる
つまり 80286のセグメンテーション を求めることになるが、これはすでに存在していたし、望むことは実現できなかった。なぜならそのセグメントディスクリプタもソフトウェアが正しくロードしなければならないからだ。ソフトウェアの観点では結局「ただのポインタ」なので、同じミスに弱い
推測実行の場合、その脆弱性を実際に何かへ使うには馬鹿げているほどの事前準備が必要になる。実際に使えるほぼ唯一の方法は、そのコンピュータに直接アクセスして低レベルコードを実行する場合だ。ブラウザで動くJSコードだけで任意の秘密を漏えいさせるような話ではない
専門の民間組織や国家支援組織が、必要な研究と標的化を行うだけの価値があるシステムなら、そもそも未許可の任意コードが実行できないようにする仕組みがあるべきだ
個人的には性能向上を実感できるので、すべての緩和策を無効にしている
Intelのセキュリティ勧告: https://www.intel.com/content/www/us/en/security-center/advi...
AMDハードウェアにも似た穴があるのか気になる。スペキュレーティブ実行は共有プロセッサ空間ではパッチが非常に難しい脆弱性のように見えるので、AMDがどう回避してきたのか気になる
評価した AMD と ARM システムでは問題は見つからなかったとのこと。
出典: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
この特定の脆弱性は Meltdown のように Intel 専用に見えるが、AMD も元々 Spectre には脆弱だった
ただし、スペキュレーティブ実行エンジンは複雑で、バグや脆弱性が非常に広範に存在している。
AMD や ARM にも似たバグがある可能性は高い。Intel でこうしたバグがどれほど長く発見されなかったかを考えればよい。
残念ながら本当の解決策は、現代のシステムで実行されるコードを隔離できないという事実を認めることだが、これは一部の非常に裕福な企業のビジネスモデルには致命的かもしれない
ソフトウェアで起きがちな問題と同じ解決法ではないか？
「こうした穴を防ぐには、プロセッサ マイクロコード の特別なアップデートが必要だ。BIOS や OS の更新で可能なので、Windows の最新の累積更新の1つとして PC にインストールされるはずだ」とあるが、なぜ Windows だけに言及するのか？ Linux ユーザーは？
ディストリビューションはここから取得して自動配布するようになっている。
ただし、この特定の緩和策がすでに入っているかを確認するには何を見ればよいのかはよく分からない
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL)を備えていた。ただし、Intel がディストリビューション管理者がパッケージを更新できるよう必要なマイクロコードファイルを公開する必要があり、その後システム更新に含まれることになる
Intel が立て直せるのか気になる。市場にはもっともらしい製品がなく、研究開発には時間がかかり、ファウンドリは競合より遅れていて損失の源泉であり続けている。
しかも x86 は ARM ハードウェアにますます押されており、今や中国発の RISC-V も伸びてきている。もちろん米国の半導体という観点もある。特にコロナ禍で問題を経験したあと、米国が Intel のような中核製造業者の崩壊を許すだろうか？
状況は良くはないが、扇情主義は滑稽なくらいだ。
ゲーマーは Intel 製品ユーザーのうち数パーセントにすぎないのに、その話ばかりが最も多く聞こえてくる。データセンターの受注1〜2件で、Intel が1年に売るゲーミング CPU 全体を上回る。Intel は依然としてデータセンター市場でよく踏みとどまっている。
さらに Intel は企業向けノートPC市場も依然として支配しており、この市場もゲーマー市場よりかなり大きい
Arm は昨年のデータセンター市場シェアが 15% にすぎず、Windows 市場でもまだ大きな進展はない
製品とは別に、株主・事業の観点では最近の財務実績は最終製品をますます反映しなくなっていると思うので分けて考えたいが、Intel は 大きすぎて潰せない に近いと思う
ちゃんと理解できているか確認したいのだが、現時点では主要な OS はすべてこの問題を緩和するか、関連する マイクロコード を適用するパッチが出ているのか？