ZenHammer: AMD Zenベースのプラットフォームを狙ったRowhammer攻撃
(comsec.ethz.ch)- TRR緩和策が適用されたAMD Zen 2・Zen 3 DDR4システムでもRowhammerのビット反転が発生し、AMDプラットフォームも実質的な攻撃対象になり得る
- 研究チームはAMD向けに調整したDRAMA手法で秘密のDRAMアドレス関数をリバースエンジニアリングし、システムアドレスの再マッピングのため物理アドレスオフセット処理が必要であることを確認した
- ZenHammer fuzzerはSamsung、Micron、SK Hynixを含む10個のDDR4デバイスのうち、Zen 2で7個、Zen 3で6個でビット反転を誘発し、Zen 3デバイスはIntel Coffee Lakeよりも脆弱な結果を示した
- 既存のページテーブル、RSA-2048公開鍵破壊、
sudoers.so攻撃はそれぞれ7/6/4個のデバイスで構成可能であり、悪用可能なビット反転を見つける平均時間は164/267/209秒だった - Zen 4のDDR5評価では、10個中1個のデバイスで約42,000個のビット反転が発生したが、残り9個では失敗しており、DDR5には追加のパターン研究が必要である
AMD Zenでも発生したRowhammerビット反転
- ZenHammerは、TRR緩和策が適用されたDDR4デバイスでAMD Zen 2およびZen 3システムのRowhammerビット反転を誘発した
- AMDシステムもIntelシステムと同様にRowhammer脆弱性を持ち得ることが確認された
- AMDのx86デスクトップCPU市場シェアは約**36%**であり、攻撃対象は小さくない
- DRAMデバイスは配備後に容易に修正できず、これまでの研究ではRowhammer攻撃がさまざまな環境で実用的になり得ることが示されている
AMD DRAMアドレス関数のリバースエンジニアリングとハンマリング最適化
- AMDシステム向けにDRAMA手法を適用し、秘密のDRAMアドレス関数をリバースエンジニアリングした
- より安定した結果を得るためにタイミングルーチンを変更した
- システムアドレスの再マッピングのため、DRAMアドレス関数を復元する前に物理アドレスオフセットを適用する必要があり、これによってアドレス関数を完全に復元した
- 復元したアドレス関数だけを使う方式では、ビット反転数は限定的だった
- Zen 2では10個のデバイス中5個でのみビット反転が確認された
- Zen 3では10個のデバイス中0個でビット反転が確認された
リフレッシュ同期とコマンドシーケンス
- 先行研究のSMASHやBlacksmithと同様に、リフレッシュ同期がビット反転誘発の重要要素だった
- AMDでは、反復しない行を対象に連続したタイミング測定を行う方式が、精密で信頼性の高いリフレッシュ同期に有効だった
- AMD Zen+/3システムでは、非均一なRowhammerパターンの活性化率がIntel Coffee Lakeより大幅に低かった
- 最適なハンマリング用コマンドシーケンスは、通常のロード
MOVとCLFLUSHOPTを使ってaggressorをキャッシュからフラッシュし、aggressorアクセス直後にフラッシュする「scatter」スタイルだった - Zen 2と異なり、Zen 3ではフラッシュ後に明示的なfenceは不要だった
- fenceの種類とfenceスケジューリング方針も結果に影響し、研究チームは6種類のパターン認識・キャッシュ回避方針を提案して、デバイスごとに6時間ずつテストした
- Zen 2の大半のデバイスでは
SP_noneが最適だった - Zen 3の大半のケースでは
SP_pairがより適していた
- Zen 2の大半のデバイスでは
DDR4評価結果と悪用可能性
- 評価はSamsung、Micron、SK Hynixを含む10個のDDR4 DRAMデバイスを対象に行われた
- ZenHammer fuzzerは、各fence種類である
mfence、sfenceと各fenceスケジューリング方針の組み合わせごとに3時間ずつ実行された - 各実行後には、発見されたすべてのパターンで4MiB範囲のminisweepを行って最適パターンを決め、最適方針の最適パターンを256MBの連続メモリ領域に対してsweepした
- その結果、DDR4 DRAMデバイス10個のうちZen 2で7個、Zen 3で6個でビット反転が発生した
- ビット反転の悪用可能性は既存研究の3種類の攻撃で評価された
- ページテーブルエントリのpage frame numberを攻撃し、攻撃者制御のページテーブルページへピボットする攻撃
- SSHホスト認証に使われる関連秘密鍵の復元を可能にするRSA-2048公開鍵攻撃
- root権限の取得を可能にする
sudoers.soライブラリのパスワード検証ロジック攻撃
- 既存攻撃はそれぞれ7/6/4個のデバイスで構成可能であり、悪用可能なビット反転を見つける平均時間は164/267/209秒だった
DDR5評価、公開コード、発表予定
- AMD Zen 4でDDR5 DRAM関数もリバースエンジニアリングし、10個のDDR5デバイスを評価した
- ZenHammerは10個中1個のDDR5デバイスで約42,000個のビット反転を誘発した
- これは一般的な商用システムでDDR5ビット反転を公に報告した最初の事例である
- 残り9個のDDR5デバイスではビット反転が発生せず、DDR5デバイスにはより効果的なパターンを見つけるための追加研究が必要である
- 詳細全体は、2024年8月のUSENIX Security 2024で発表される論文に含まれている
- ZenHammer fuzzerのコードはGitHubで提供されており、AMD Zen 2/3/4 CPUでDRAMデバイスにビット反転が起きるかを評価するために利用できる
- Rowhammerは業界全体で知られた問題であり、一般的な公開手順は不要と判断したが、AMDには2024年2月26日に通知し、AMDの要請により2024年3月25日までは公開しなかった
- このページは誤って2024年3月21日に一時的にオンライン公開されていた
FAQの実務上の制約
- AMDシステムがこれまであまり扱われてこなかった理由は、元のRowhammer研究でIntelシステムのビット反転数がはるかに多く、その後の研究も主にIntelへ集中していたこと、さらにIntel CPUマイクロアーキテクチャの情報がAMDより多く知られていたためである
- 10個のDDR4デバイスのうちZen 2では3個、Zen 3では4個でビット反転が発生しなかったが、Intel Coffee Lakeでもこれらのデバイスのビット反転数は少なかったため、fuzzerをさらに調整すればビット反転が現れる可能性があると見ている
- 評価デバイス数が10個に限られた理由は、研究室のAMD Zen 2/3機材数が限られており、一部実験に長時間を要したためであり、無作為な部分集合には3社のDRAM供給元デバイスがすべて含まれている
- JEDECがまだ問題を修正できていない理由については、Rowhammer対策は難しいが不可能ではなく、先行研究のProTRRとREGAでそれが示されていると説明している
- DDR3に関する先行研究はECCがRowhammerを防げないことを示しており、現在のDDR4デバイスではビット反転数がより多いため、ECCは完全な保護ではなく、悪用をより困難にする程度と考えられる
- リフレッシュ率を2倍にする方式は性能オーバーヘッドと消費電力増加を伴い、Mutlu et al.やFrigo et al.などの先行研究でも完全な保護を提供できない弱い解決策とされている
1件のコメント
Hacker Newsのコメント
もともとRowhammerエクスプロイトの共同著者だ。ECCは、この問題をセキュリティ問題から信頼性問題へと大きく変えるうえで、今でも非常に有効だ。
個人でサーバーを所有しているなら、そのサーバーにECCがあり、訂正不能なECCエラーによるマシン停止に気付けると期待できるなら、セキュリティ上の影響は大きくない。
ただし、マルチテナントホストでVMを提供するクラウド事業者であれば、脅威モデルは異なりうる。
いずれにせよECCなしのマシンは避けるべきだ。TRRはRowhammerが知られ始めた当時ですら既に破綻した防御であり、DRAM製造の経済性が変わらない限り、DRAMのビット反転はなくならない
RyzenがサポートしているのはアンバッファードECCだけで、同容量の非ECCメモリより遅いか高いか、あるいはその両方だ。
最新のThreadripperラインアップはRegistered ECCをサポートしているが、私のような家庭ユーザーにはコスト・スレッド数・PCIeレーンのすべてが過剰だ
セキュリティリスクは大きすぎ、あらゆるものが高度に統合されているので、この変化を先延ばしにするのは難しい。純粋にゲーム用のコンピュータを使うゲーマーでさえ重要な情報をそのマシンに置くだろうし、今までこの変化が起きなかったのが理解できない
本当に耐性があるのはSRAMだけなのかも気になる
保証されているのはProとThreadripperだけで、一部のデスクトップRyzenは一部のマザーボードでのみ可能だ
Rowhammerで誘発されるビット反転に安全に先回りするには、パトロールリードエンジンはどれほど積極的にDRAMをスキャンすべきなのか。
従来の64+8より大きいECCワードと多ビット誤り訂正があれば、パターン脆弱性のあるDRAMでも、より信頼性の高いシステムを作れるほど状況は変わるのか
「ECCはRowhammerを防げない」といった表現は非常に誤解を招く。引用された論文でも「ECC検出が正しく使われている場合でも、全ビット反転の0.65%〜7.42%がサイレント破損を引き起こす…AMD-1構成では訂正不能エラーがシステムをクラッシュさせる」と述べている。
攻撃者が悪用可能なビット反転を1つ得るには、何十回ものマシン停止を引き起こさなければならない。何十回ものマシン停止は、気付かれずに済むようなものではない。
JEDECのRowhammer対策がひどい点を指摘したのはよいが、短期的解決策としてのECCを過小評価すべきではない
Zen2 TRプラットフォームなので、その文言を見て一瞬ヒヤッとした。かなり誤解を招く表現だ
一般の人にとって、Rowhammer、Spectre、Meltdownのようなハードウェアセキュリティ問題が実際にリスクなのか気になる。
SpectreとMeltdownはVM脱出のような攻撃で問題になるものと理解していたので、AWSのエンジニアが気にすべきことであって、個人ユーザー向けではないように見えていた
そして現代社会と縁を切ったのだから、森の中の小屋へ行って自給自足すればいい
個人的にはNoScriptが好きだ。Chromeでは何を選べばいいのかよく分からない。
それ以外では……インターネット上の任意のプログラムを頻繁に実行したりはしないだろう？
この種のバグはまだ表面を少しかすった程度だ。現代のハードウェアは複雑すぎて、全部見つけられると信じるのは難しい
だから誰もが影響を受けうる
DDRのビットフリップ攻撃についてはごくおぼろげにしか理解していなかったが、元のHammertime論文を見てみると実際かなり読みやすい。
まだ全部は読んでいないが、理解しやすいようにうまく説明されている。ビットフリップという言葉は何度も聞いていたのに、きちんと理解したことはなかったが、これを見て感覚がつかめた。
https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
電気電子の入門授業をひとつ受けたような気分だ。これが実際のハードウェア製造上の欠陥に関係しているとはまったく知らなかった。
Rowhammerという名前もそこでやっと説明がついた。自分があまりに遅れていただけで、みんな知っている話なのかもしれない。
「現代のDRAMアレイの極端な高密度化により、小さな製造欠陥が隣接セル間に弱い電気的結合を生むことがある。こうしたセルのごく小さな静電容量と組み合わさると、DRAMの行がバンクから読み出されるたびに隣接行のメモリセルは少量の電荷を失う。これが2回のリフレッシュ周期の間に十分高頻度で発生すると、影響を受けたセルは保存しているビット値が反転するほど電荷を失う可能性があり、これを『disturbance error』、あるいは近年ではRowhammerと呼ぶ」
DRAMメーカーが限界を極端にまで押し広げたからだ。利益追求である。
負傷や死亡に関するPinto訴訟の和解費用のほうが車両設計の修正費用より低いと判断したFordと変わらない。
Secure Memory Encryptionがこれに役立つのか気になる。
https://www.amd.com/en/developer/sev.html
ビットフリップ1つだけでも致命的なエラーになりうる。
ハードウェアセキュリティには疎いのだが、これはCPU最適化で生じる数多くの必然的な脆弱性のひとつで、現実には実現可能性が低い部類なのだろうか。
サイドチャネルで情報を漏らす機能の境界事例より、はるかに低いレベルで起きる。
データは格子の中の小さな電荷として保存されており、近くの格子点を何度も反転させると、標的の電荷のほうへ一部の電荷を漏れ出させることができる。
電荷が小さく、互いに近いほどRowhammer攻撃は容易になる。同時に、電荷が小さく近いほどRAMはより高速で安価かつ高密度で効率的になる。
緩和策はあるが、すでに限界まで押し進められている。
全メモリ暗号化、ポイズニング、アドレスXORを有効にしてもこれが動作するのか気になる。
だからメモリ暗号化を使うほうがより安全だ。
「ZenHammerは10台中9台ではフリップを引き起こせなかった…DDR5デバイスに対してより効果的なパターンを見つけるには追加研究が必要だ」というなら、DDR5にはまだ少し猶予があるようにも思える。
これがLPDDR5xにも影響するのか知っている人がいるだろうか。
そのため、DDR5、LPDDR5(x)、GDDR6(x)、HBM3(e)のどれであるかは本質的な問いではない。
重要なのは、オンダイECCのようなメーカー裁量の実装詳細だ。
Zen 2と3には言及があるが、Zen 1についての情報はあるのだろうか。
単に同じように適用されるのだろうか?