パスワードを忘れた? アカウント作成
15701125 story
AMD

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によって展開されているとのことで、深刻な問題にはならない模様。
  • by misz (9022) on 2022年06月16日 12時08分 (#4270352)
    IntelではなくAMDなのは何故?
    ここに返信
  • by Anonymous Coward on 2022年06月16日 12時17分 (#4270355)

    どのくらいの暗号強度でどのくらいの時間でバレたのかの情報が見つけれれませんでしたので
    もしかすると
    最も弱い組み合わせなら現実的な時間で漏れるが
    ワンタイム用に適切な強度で用いるなどであれば現実的な驚異とはならない
    だったりするかもしれない
    なのでもうちょい情報待ちしてから騒いでもいいのかなと

    ここに返信
    • by Anonymous Coward

      > どのくらいの暗号強度でどのくらいの時間でバレたのかの情報が見つけれれませんでしたので

      タレコミの最初のリンク先に,FAQ,論文のpdf,しっかり情報が用意されているのに何言ってるんですか?

      どうせ見てないんだろうからリンクを貼っておきます
      https://www.hertzbleed.com/ [hertzbleed.com]
      https://www.hertzbleed.com/hertzbleed.pdf [hertzbleed.com]

      これ読んでから出直して来てください

      • Re: (スコア:0, おもしろおかしい)

        by Anonymous Coward

        お前リアルでもそんな人の神経逆なでするような言い方してんの?その内殺されちゃうよ

        • by Anonymous Coward

          セルフおもおかとは、おもしろおかしいね

        • by Anonymous Coward

          大丈夫。リアルでは正反対です。

        • by Anonymous Coward

          > お前リアルでもそんな人の神経逆なでするような言い方してんの?その内殺されちゃうよ

          正当防衛って知ってますか?殺されそうになったら,先に殺しちゃえばいいんですよ

  • by Anonymous Coward on 2022年06月16日 13時38分 (#4270404)

    > 「計算処理の実行時間が消費電力に依存する」
     
    あたりまえやん。なぜこれで暗号化キーがわかるのか...
    よくこんなこと思いつくなぁ。すごい。

    ここに返信
    • by Anonymous Coward on 2022年06月16日 15時25分 (#4270502)

      ものすごく単純なところだと、「入力されたパスワード」と「正しいパスワード」が等しいかどうかを、

      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の周波数が高まって、
      そこそこ重たい方の通信速度が変動して観察できる、とかそういう。

      • by Anonymous Coward

        パスワード比較でforの中にreturnがあるようなのはそもそも普通に脆弱性ですね。

        消費電力量を測定できるような環境下で、ALUへの入出力に応じて(例えば変化するビットの数に依存して)消費電力が変化することを利用して
        測定結果から内部の情報がばれることがあるのが前回までのあらすじ。

        今回は、消費電力が高くなると発熱が大きくなり、クロックが低下することを利用して消費電力量測定を不要としたのが大きい。

        • by Anonymous Coward

          >今回は、消費電力が高くなると発熱が大きくなり、クロックが低下することを利用して消費電力量測定を不要としたのが大きい。

          惜しい。
          最近の CPU は温度だけでなくて、CPU の消費電力を直接見ていて、消費電力が少ないと、自動的にオーバークロックで動作する。このオーバークロックで速くなった部分を観測している。発熱による温度変化は間接的で緩やかだけど、最近の CPU は消費電力に敏感に反応してクロックを変えるので、観測しやすい。

        • by Anonymous Coward

          基本は効率犠牲に失敗内容別にコストが変動しないように設計すると思うが
          鍵を扱う処理または回路の設計に必要な要件がまた増えちまうなぁ……

    • by Anonymous Coward

      とはいえ、AES-NIやPadLockなどの専用回路を使うことで多少は違いが出るのではなかろうか

      • by Anonymous Coward

        とはいえ、AES-NIやPadLockなどの専用回路を使うことで多少は違いが出るのではなかろうか

        でも性能喧伝のためAES-NIやPadLockがこんなに頑張ってますと言おうとして漏れ口作っちゃうんじゃないかな

    • by Anonymous Coward

      消費電力や発熱を観察することで分岐がどっちに行ったか分かるという攻撃手法自体は昔からある
      つい五年前くらいまで対象はクレカや認証ICチップ程度に限られてたけど

  • by Anonymous Coward on 2022年06月16日 14時02分 (#4270421)

    リンク先より
    >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]押せば解決じゃないか。

    ここに返信
    • by Anonymous Coward

      Turbo BoostのないCPU(最近のはしらんけど、以前はCore i3以下のは固定じゃなかったっけ? )なら脆弱性なし?
      Turboじゃなくても動作周波数は負荷の大小により可変だったような。

      • by Anonymous Coward

        TB非対応でもEISTがあるので可変

        • by Anonymous Coward

          > TB非対応でもEISTがあるので可変
          意味不明。
          あと今回のはどっちかというと SpeedStep ではなく HWP。

      • by Anonymous Coward

        この研究はTurbo Boostの挙動に絞り込んで検証してるので、TBを切ると前提が壊れる
        そういう意味では切れば脆弱性なしだけど、残りの可変機能については何とも言えない

        根本的には暗号処理を外部CPUに切り出すなどするのが正解

        • by Anonymous Coward

          根本的には暗号処理を外部CPUに切り出すなどするのが正解

          けど外部にしたところでそっちのパフォーマンス情報見るツール出しちゃうと元の木阿弥なのだがね

    • by Anonymous Coward

      鍵の一致状況で電力変動を起こさない実装でも解決できるのでそっちのほうが効率面では筋がいい筈。
      というか最近はそうなってるのと違うのか?

  • by Anonymous Coward on 2022年06月16日 15時24分 (#4270501)

    もうすでに64bitになってませんでしたっけ?

    最新のx86プロセッサ って Haswellぐらいか?
    とかおもって元見たら
    第8世代~第11世代のIntel製CPU だった。
    アーキテクチャ やっぱりx64じゃね?

    ここに返信
    • by Anonymous Coward

      別にx86-64と書いてもいいんだろうけど既にx64で普通は通じるからx64と書いているものと思われます。

    • by Anonymous Coward

      もうすでに64bitになってませんでしたっけ?

      x64はx86命令セットと互換性を持っているので広義にはx86にx64を含める場合がある
      今回は可変クロックのx86系まるごとの意味だから間違ってないんじゃないかな
      x64て言っちゃうとSpeedStep第一世のMobile Pentium IIIは含まれず脆弱性対象外ってことになる

      • Intel は "all Intel(R) processors are affected." と言っておられるよ
        // ということは4004もか? (とりあえず言っておけ
        • by Anonymous Coward on 2022年06月16日 17時29分 (#4270599)

          Intel は "all Intel(R) processors are affected." と言っておられるよ
          // ということは4004もか? (とりあえず言っておけ

          クロック可変版4004の検索結果は404ではないかと

        • by Anonymous Coward

          > Intel は "all Intel(R) processors are affected."
          その all はサポートしているCPU前提の話だ。End of Support なやつは関係ない。

        • by Anonymous Coward

          // ということは4004もか? (とりあえず言っておけ

          そもそも、プロテクトモードがないのでは?

          • by Anonymous Coward

            そもそも、クラック用のソフトを動作させるメモリサイズがない
            そもそもそ、稼働している(ネットにつながった)個体がない
            # あるのか?

  • by Anonymous Coward on 2022年06月16日 17時58分 (#4270638)

    Heartbleedに見えて、今更?と思った
    //こういうのって命名規則とかないんですかね

    ここに返信
  • by Anonymous Coward on 2022年06月17日 5時57分 (#4270897)

    >Intelが一般公開の延期を求めた理由は不明とのことです。
    2021年第3四半期にIntelがこの脆弱性の報告を受けてから
    お抱えの最強ホワイトハッカーチームがAMDでも再現できることを
    証明するための時間稼ぎだったのだー(棒)

    ここに返信
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...