x86 CPUに新たなサイドチャネル脆弱性「Hertzbleed」が見つかる。リモートでも攻撃可能 45
ストーリー by nagazou
今回そこまで深刻ではないそうです 部門より
今回そこまで深刻ではないそうです 部門より
テキサス大学やイリノイ大学らの研究チームは14日、最新のx86プロセッサに新たなサイドチャネル攻撃が可能な脆弱性「Hertzbleed Attack」があったと発表した。研究チームはHertzbleed Attackを用いることで、対象となるCPUの暗号化を突破できると主張しているそうだ（Hertzbleed Attack、窓の杜、GIGAZINE）。
この攻撃は周波数を動的に変更して消費電力を削減するIntelの「Turbo Boost」やAMDの「Precision Boost」といった周波数スケーリング技術と単純電力解析のサイドチャネル攻撃を組み合わせて実現しているようだ。周波数スケーリング技術に存在する「計算処理の実行時間が消費電力に依存する」という特徴を悪用したという。研究チームはこの脆弱性を用いて、実際に暗号アルゴリズム「SIKE」の暗号化キーをリモート取得することに成功したとしている。
影響を受けるCPUに関してはIntel製プロセッサに関してはすべてで、同社は開発者向けにHertzbleed Attackの対策ガイダンスを公開している。脆弱性の深刻度はCVSSのベーススコアで「6.3」（Medium）となっている（Frequency Throttling Side Channel Guidance）。AMD製プロセッサに関しても、Ryzen ThreadripperやRyzen 2000シリーズ以降のCPUといった比較的新しいものに関してはほぼすべてに影響があるようだ（Frequency Scaling Timing Power Side-Channels）。
ただ研究者らが提案した緩和策が、CloudflareやMicrosoftによって展開されているとのことで、深刻な問題にはならない模様。
この攻撃は周波数を動的に変更して消費電力を削減するIntelの「Turbo Boost」やAMDの「Precision Boost」といった周波数スケーリング技術と単純電力解析のサイドチャネル攻撃を組み合わせて実現しているようだ。周波数スケーリング技術に存在する「計算処理の実行時間が消費電力に依存する」という特徴を悪用したという。研究チームはこの脆弱性を用いて、実際に暗号アルゴリズム「SIKE」の暗号化キーをリモート取得することに成功したとしている。
影響を受けるCPUに関してはIntel製プロセッサに関してはすべてで、同社は開発者向けにHertzbleed Attackの対策ガイダンスを公開している。脆弱性の深刻度はCVSSのベーススコアで「6.3」（Medium）となっている（Frequency Throttling Side Channel Guidance）。AMD製プロセッサに関しても、Ryzen ThreadripperやRyzen 2000シリーズ以降のCPUといった比較的新しいものに関してはほぼすべてに影響があるようだ（Frequency Scaling Timing Power Side-Channels）。
ただ研究者らが提案した緩和策が、CloudflareやMicrosoftによって展開されているとのことで、深刻な問題にはならない模様。
何故アイコンがAMD? (スコア:1)
Re:何故アイコンがAMD? (スコア:1)
amd64アーキテクチャだからかも。
Re: (スコア:0)
公開されている情報を読む限り、命令アーキテクチャは本件では無関係っぽいですよ。
原理的に可能なことはわかるんだが (スコア:0)
どのくらいの暗号強度でどのくらいの時間でバレたのかの情報が見つけれれませんでしたので
もしかすると
最も弱い組み合わせなら現実的な時間で漏れるが
ワンタイム用に適切な強度で用いるなどであれば現実的な驚異とはならない
だったりするかもしれない
なのでもうちょい情報待ちしてから騒いでもいいのかなと
Re: (スコア:0)
> どのくらいの暗号強度でどのくらいの時間でバレたのかの情報が見つけれれませんでしたので
タレコミの最初のリンク先に，FAQ，論文のpdf，しっかり情報が用意されているのに何言ってるんですか？
どうせ見てないんだろうからリンクを貼っておきます
https://www.hertzbleed.com/ [hertzbleed.com]
https://www.hertzbleed.com/hertzbleed.pdf [hertzbleed.com]
これ読んでから出直して来てください
Re: (スコア:0, おもしろおかしい)
お前リアルでもそんな人の神経逆なでするような言い方してんの？その内殺されちゃうよ
Re: (スコア:0)
セルフおもおかとは、おもしろおかしいね
Re: (スコア:0)
大丈夫。リアルでは正反対です。
Re: (スコア:0)
> お前リアルでもそんな人の神経逆なでするような言い方してんの？その内殺されちゃうよ
正当防衛って知ってますか？殺されそうになったら，先に殺しちゃえばいいんですよ
Re:原理的に可能なことはわかるんだが (スコア:1)
GPT-3でももうちょっとマシなレスバできるだろ
Re: (スコア:0)
よかった、スラドに可哀そうな人工知能はいなかったんだ
Re: (スコア:0)
可愛い人工知能がいないかな？
Re:原理的に可能なことはわかるんだが (スコア:1)
お前の方が可愛いよ
Re: (スコア:0)
動揺しすぎだろ
Re: (スコア:0)
出たばっかの論文にアホなこと言ってる暇があるなら自分で検証すればいい。
Re: (スコア:0)
「情報がない」という意見に対して「情報はここにあります」と返したらこれ。
あほだな（断定）。
Re: (スコア:0)
発表があったばかりの件について他の情報源があることを期待してる方があほに見えるな。
Re: (スコア:0)
パクリ逆張りと感情論と憎悪煽りくらいしかする気がないから、パクリ元がないとこうなっちゃうんじゃない
生きた人間のやることとは思えないけど、そういう人間ならしょうがないかもしれない
なるほどわからん (スコア:0)
> 「計算処理の実行時間が消費電力に依存する」
あたりまえやん。なぜこれで暗号化キーがわかるのか...
よくこんなこと思いつくなぁ。すごい。
Re:なるほどわからん (スコア:2, 興味深い)
ものすごく単純なところだと、「入力されたパスワード」と「正しいパスワード」が等しいかどうかを、
for(int i = 0; i < パスワード長; i ++){
if(入力されたパスワード[i] != 正しいパスワード[i]){
return false;
}
}
return true;
みたいな処理で判定していると「1文字目からいきなりが外れ」と「1文字目はセーブで2文字目が外れ」だと、
後者の方が、ちょっとだけ処理に時間が掛かる。CPU時間をより多く消費する。
通らないのを前提に、1文字目の可能性を全パターン試して、1個だけ結果が帰って来るのが遅かったら、それが1文字目と確定する。
1文字目を揃えて、同じように2文字目の全パターンを試して、3文字目を試して、とやってくと、最終的にはパスワード全部が分かる。
というところまでが前回までのあらすじで、今回はリモートでCPUの周波数の変動でその違いを観察できるって話かな。
攻撃対象のサーバとそこそこ重たい通信をしつつ、それとは別途、パスワードかなにかをクラックするための通信を始める。
クラック用の方の通信であれこれデータを投げつけると、その処理の仕方によってはCPUの周波数が高まって、
そこそこ重たい方の通信速度が変動して観察できる、とかそういう。
Re: (スコア:0)
パスワード比較でforの中にreturnがあるようなのはそもそも普通に脆弱性ですね。
消費電力量を測定できるような環境下で、ALUへの入出力に応じて(例えば変化するビットの数に依存して)消費電力が変化することを利用して
測定結果から内部の情報がばれることがあるのが前回までのあらすじ。
今回は、消費電力が高くなると発熱が大きくなり、クロックが低下することを利用して消費電力量測定を不要としたのが大きい。
Re: (スコア:0)
>今回は、消費電力が高くなると発熱が大きくなり、クロックが低下することを利用して消費電力量測定を不要としたのが大きい。
惜しい。
最近の CPU は温度だけでなくて、CPU の消費電力を直接見ていて、消費電力が少ないと、自動的にオーバークロックで動作する。このオーバークロックで速くなった部分を観測している。発熱による温度変化は間接的で緩やかだけど、最近の CPU は消費電力に敏感に反応してクロックを変えるので、観測しやすい。
Re: (スコア:0)
基本は効率犠牲に失敗内容別にコストが変動しないように設計すると思うが
鍵を扱う処理または回路の設計に必要な要件がまた増えちまうなぁ……
Re: (スコア:0)
とはいえ、AES-NIやPadLockなどの専用回路を使うことで多少は違いが出るのではなかろうか
Re: (スコア:0)
とはいえ、AES-NIやPadLockなどの専用回路を使うことで多少は違いが出るのではなかろうか
でも性能喧伝のためAES-NIやPadLockがこんなに頑張ってますと言おうとして漏れ口作っちゃうんじゃないかな
Re: (スコア:0)
消費電力や発熱を観察することで分岐がどっちに行ったか分かるという攻撃手法自体は昔からある
つい五年前くらいまで対象はクレカや認証ICチップ程度に限られてたけど
昔のPCは時代を先取りしてたんだな。 (スコア:0)
リンク先より
＞Is there a workaround?
＞Technically, yes. However, it has a significant system-wide performance impact.
＞In most cases, a workload-independent workaround to mitigate Hertzbleed is to disable frequency
＞boost. Intel calls this feature “Turbo Boost”, and AMD calls it “Turbo Core” or “Precision
＞Boost”.
回避策はありますか？
技術的にはあります。ただし、システム全体のパフォーマンスに大きな影響があります。
ほとんどの場合、Hertzbleedを軽減するためのワークロードに依存しない回避策は、周波数ブーストを無効にすることです。 Intelはこの機能を「TurboBoost」と呼び、AMDはこれを「TurboCore」または「PrecisionBoost」と呼んでいます。
なんだ、Turboボタン [wikipedia.org]押せば解決じゃないか。
Re: (スコア:0)
Turbo BoostのないCPU（最近のはしらんけど、以前はCore i3以下のは固定じゃなかったっけ？ )なら脆弱性なし？
Turboじゃなくても動作周波数は負荷の大小により可変だったような。
Re: (スコア:0)
TB非対応でもEISTがあるので可変
Re: (スコア:0)
> TB非対応でもEISTがあるので可変
意味不明。
あと今回のはどっちかというと SpeedStep ではなく HWP。
Re: (スコア:0)
この研究はTurbo Boostの挙動に絞り込んで検証してるので、TBを切ると前提が壊れる
そういう意味では切れば脆弱性なしだけど、残りの可変機能については何とも言えない
根本的には暗号処理を外部CPUに切り出すなどするのが正解
Re: (スコア:0)
根本的には暗号処理を外部CPUに切り出すなどするのが正解
けど外部にしたところでそっちのパフォーマンス情報見るツール出しちゃうと元の木阿弥なのだがね
Re: (スコア:0)
鍵の一致状況で電力変動を起こさない実装でも解決できるのでそっちのほうが効率面では筋がいい筈。
というか最近はそうなってるのと違うのか？
最新のx86プロセッサ？ (スコア:0)
もうすでに64bitになってませんでしたっけ？
最新のx86プロセッサ って Haswellぐらいか？
とかおもって元見たら
第8世代～第11世代のIntel製CPU だった。
アーキテクチャ やっぱりx64じゃね？
Re: (スコア:0)
別にx86-64と書いてもいいんだろうけど既にx64で普通は通じるからx64と書いているものと思われます。
Re: (スコア:0)
もうすでに64bitになってませんでしたっけ？
x64はx86命令セットと互換性を持っているので広義にはx86にx64を含める場合がある
今回は可変クロックのx86系まるごとの意味だから間違ってないんじゃないかな
x64て言っちゃうとSpeedStep第一世のMobile Pentium IIIは含まれず脆弱性対象外ってことになる
Re:最新のx86プロセッサ？ (スコア:1)
// ということは4004もか? (とりあえず言っておけ
Re:最新のx86プロセッサ？ (スコア:1)
Intel は "all Intel(R) processors are affected." と言っておられるよ
// ということは4004もか? (とりあえず言っておけ
クロック可変版4004の検索結果は404ではないかと
Re: (スコア:0)
> Intel は "all Intel(R) processors are affected."
その all はサポートしているCPU前提の話だ。End of Support なやつは関係ない。
Re: (スコア:0)
// ということは4004もか? (とりあえず言っておけ
そもそも、プロテクトモードがないのでは？
Re: (スコア:0)
そもそも、クラック用のソフトを動作させるメモリサイズがない
そもそもそ、稼働している(ネットにつながった)個体がない
# あるのか?
空目 (スコア:0)
Heartbleedに見えて、今更？と思った
//こういうのって命名規則とかないんですかね
陰謀論 (スコア:-128, フレームのもと) (スコア:0)
>Intelが一般公開の延期を求めた理由は不明とのことです。
2021年第3四半期にIntelがこの脆弱性の報告を受けてから
お抱えの最強ホワイトハッカーチームがAMDでも再現できることを
証明するための時間稼ぎだったのだー(棒)