パスワードを忘れた? アカウント作成
13849451 story
セキュリティ

Googleの研究者ら曰く、Spectre脆弱性の修正は難しい 62

ストーリー by hylom
今後も似たような問題は続くのか 部門より
あるAnonymous Coward曰く、

昨年1月に「Spectre」などと呼ばれるCPUの脆弱性の存在が報じられた。その後、これらと同様の手法を使った攻撃手法が次々と見つかっているが、Googleの研究者らが2月15日付けで発表した論文によると、これらの脆弱性は修正が難しいという(I Programmer)。

論文では、Spectre脆弱性は投機実行機能を持つすべてのCPUに存在する、プロセス分離という概念は滅びた、個々のソフトウェア実装どころかプログラミング言語でもハードウェアでも解決できない、という事実を改めて明らかにしたうえで、まずサイドチャネル攻撃を模擬して分析できるCPUの状態モデルを作り、その状態モデルを操作できるようにするところから始めないと、脆弱性の解消どころか研究すら手が付けられないとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • マイナー OS/2 最高www (スコア:3, おもしろおかしい)

    by SassyOS2 (8523) on 2019年02月28日 19時13分 (#3572854) ホームページ 日記

    Policy statement concerning Spectre and Meltdown exploits [arcanoae.com]

    In order to gain access to any information in privileged memory using one of these exploits, a user-level application must be launched on the specific machine to be compromised. This means that presently, an OS/2 executable must be used as the attack vector. As of this writing, we are not aware of any such code which executes on the OS/2 platform.

    Browser-based attacks (running JavaScript) appear to require greater precision in a high-resolution timer than is currently available on OS/2, making such exploits more difficult than on other platforms, if not altogether impossible. It should also be noted that any such JavaScript-based attack would have to also be specifically designed to handle access to memory regions as managed by OS/2 (in other words, a malicious JavaScript program must be written for OS/2 and specifically to run in the OS/2 browser version in which it is running; a JavaScript program written for Windows or Linux will not work on OS/2). Realistically, the chance of this level of coding detail is extremely small.

    どうしても攻撃コードはプラットフォーム依存になるからマイナー OS/2 は狙われにくいというお話。さあみんな OS/2 を使おうよ。

    # というコメントを Windows 10 の Firefox で書いていますw

    • by Anonymous Coward on 2019年02月28日 20時23分 (#3572903)

      そういってOS/2に人が集まると元の木阿弥

      #OS/2なんて孤高の存在でこそ意義がある

      親コメント
    • by Anonymous Coward

      OS/2で良いの?
      最新のArcaOSの方が更にユーザー数少なそうだが

      • by Anonymous Coward

        スマホOSみたいな宝の山に比べたらOS/2狙うとか狂気の沙汰としか思えんが。

    • by Anonymous Coward

      マックは(マイナーだから)ウィルスがいないとか言ってた時代を思い出すな

    • by Anonymous Coward

      BeOSならもっと安心ですね

    • by Anonymous Coward

      やはり超漢字は素晴らしいということか

      • by Anonymous Coward

        残念ながら今の超漢字はWindows版のVMware上でしか起動しない
        直接ブート出来ないので意味無いです

    • by Anonymous Coward

      そこでUNIXの正統後継たるInfernoですよ!

    • by Anonymous Coward

      MIPS64で動くNetBSD
      とかのほうがはるかに狙われにくい

    • by Anonymous Coward

      緩和策を取ってリスクを減らしたが0にはできないという文脈で、うちのOSならリスクが低いと言われてもという気分ですが

      * 今時のブラウザが動く
      * 同じマシンを複数ユーザーで使うための仮想化やコンテナをサポートしている
      * 各アプリは独立していて、他のアプリの情報のアクセスにはOSレベルでの許可・不許可のAPIを通す必要がある

      といった環境でないと、この種の脆弱性は大して意味を持たないのも確かですね。マイナーOSで上記を満たす物とかありませんかね。

  • 4.5 Implementation in a Production JavaScript VM
    As part of our offensive work, we developed proofs of concept in C++, JavaScript, and WebAssembly for all the reported vulnerabilities. We were able to leak over 1KB/s from variant 1 gadgets in C++ using rdtsc with 99.99% accuracy and over 10B/s from JavaScript using a low resolution timer.

    低解像度タイマーを使っても情報をリークできるよ、と。
    つまり今はブラウザベンダーが防御策としてJavaScriptの performance.now() で取得できるタイムスタンプの精度を落としているけど、安全ではないと。

    # じゃあもういっそ元の高精度に戻してくれないかなー、と思っちゃうわけですが、
    # Spectreとは別に、タイムスタンプをフィンガープリンティングに使われるから云々という理由で、Firefoxなんかは当分は精度を落としたままだそうですね。
    # もうJavaScriptではミリ秒すら取得できない世界なのかも…

    • by Anonymous Coward

      もう漏れることを前提にコーディングすべきだな

    • by Anonymous Coward

      10B/sぐらいなら盗まれたらまずい値を100ms程度の間隔で移動させ続けるだけで十分守れるんじゃないだろうか。

  • by Anonymous Coward on 2019年02月28日 22時02分 (#3572951)

    各種予測・キャッシュミスが発生したときにペナルティ(やり直し)が発生するから問題な訳で、予測をミスったらCPUは開き直って、ごみデータを返せばよいのです!

    # OSやファームウェアレベルで乱択アルゴリズム等と組み合わせれば、そういうアーキテクチャもアリだとは思う。

    • by annoymouse coward (11178) on 2019年03月01日 2時17分 (#3573040) 日記

      Spectreなどの攻撃は,投機的実行の副作用を悪用しています.
      つまり,実行時間の変化から,キャッシュのヒットとミスヒットを判定して,
      サイドチャネル攻撃を実現しています

      そして,仮に"投棄的"実行を使ったとしても,サイドチャネル攻撃の対策になり得ません.
      "投棄的"実行の副作用を悪用して,
      つまり,結果がゴミかそうじゃないか調べれば,キャッシュのヒットとミスヒットが判定できます.
      Spectraなどと同様のアプローチで攻撃が可能です.

      具体的には,投機的実行の場合は,例えば同じ計算を複数回して,その実行時間の差を調べます.
      "投棄的"実行の場合は,同じ計算を複数回して,その実行結果の差を調べるだけです.

      つまり本質的には何も解決していません.

      googleの研究者が指摘しているのはまさにこの問題です.
      サイドチャネル攻撃の根本的解決には
      投機的実行とか投棄的実行といった従来のコンピュータアーキテクチャレベルの議論や発想ではもはや対応できません.
      もっとメタな視点での新しい論理や,それに対応した新しい計算機モデルが必要だ,という主張です

      親コメント
      • by Anonymous Coward

        同じ計算をして同じ結果が得られることを前提としているので、その方法では不十分なのでは?

        • by Anonymous Coward

          ノイズを混入しても統計処理で消せるなら同じこと

      • by Anonymous Coward

        キャッシュにもガチャを導入すれば解決ですね

        • by Anonymous Coward

          陶器的実行(窯から出てきたデータをときたま破壊)

      • by Anonymous Coward

        サイドチャネル攻撃はメモリやストレージに入っている情報を直接読み取るのではなく
        情報を読み書きする時の処理時間、消費電力、放射される電磁波、音波、振動等の違いから
        間接的に情報を推測しているだけですからね。
        だから99.99%の正確さで中身を当てられるというような話が出てくる。

        キャッシュにヒットするかどうかで処理時間が変わるってそんなの当たり前じゃんていうか
        それがキャッシュってものなわけで、その特性が悪用可能というのなら
        もうキャッシュするのやめるぐらいしか抜本的な解決策はないんじゃないのって気になりますよね。
        当然、遅くなりますが。

        • by Anonymous Coward
          それだけならキャッシュにヒットしたときに確率でミスキャッシュ相当の遅延を入れるだけでいんじゃないの?
    • 初期RISCの「遅延スロット」は、ある意味そういう方向のものじゃないかな。
      予測なんてせず「とにかくパイプラインは埋めるから、それで問題がないようにコンパイラが頑張れ」の思想。

      結局、コンパイラが頑張るのは限界があってNOPを埋めるばかりであまり効率が良くないのと、
      内部実装(パイプライン段数)とべったりな関係なので内部実装を超えたアーキテクチャの維持が難しくなって、
      汎用的なCPUでの採用は廃れた感じ

      親コメント
  • by kei0 (48634) on 2019年02月28日 23時31分 (#3572994)
    機密情報を扱うとこだけ投機実行をoffにできないの? そうそう多くないだろうと予想はつくので、処理性能に対する影響も小さいと思うんだけど。 ...機密情報を扱っていることが投機実行のon/off状態から外部観測できてしまうって?
    • by Anonymous Coward

      >機密情報を扱うとこだけ投機実行をoffにできないの?

      投機実行は盗み見る側が悪用しているのであって、泥棒にそれを使うなと命じることはできないでしょう。

      • by Anonymous Coward

        できないことはないが、ハードウェア量が30-40%増えるか、互換性がなくなる
        前者はありとあらゆるものに投機的バッファを用意する解決で、後者はありとあらゆるものをケーパビリティベースにするもの

    • by Anonymous Coward

      むしろ処理性能をそこまで必要とする処理の方が多くはないのでは
      JavaScriptなんかはデフォルトは安全性重視でのろまなインタプリタで実行させて、ユーザーが許可したときだけ高速な方法で実行すればいい

      • by Anonymous Coward

        100ミリ秒くらい遅延するだけでコンバージョン率が全然違うんで、
        商売でWeb書いてる身としては受け入れられないっす
        シンプルなWebに戻れ?
        華やかなWebサイトに客取られるだけっす
        ただ、世の全体が全体で遅延するなら構わないんで、ブラウザベンダとユーザーに「あなた方は高速なWebサイトを求めていないはずだ!」と啓蒙して回ってくださいっす。

    • by Anonymous Coward

      まさにそういう新しいCPUモデルを考えないとダメよ。というのが今回の研究内容。

    • by Anonymous Coward

      (Intelの場合で言うと)昔懐かしN270相当というかBonnell一族なセキュア用インオーダ型サブCPUコアをおまけ(?)で足して、どうにかして(無茶振り)対応OSが必要に応じて追加命令を使ってサブCPUコアで実行とか?

  • by Anonymous Coward on 2019年02月28日 18時54分 (#3572844)

    >>その状態モデルを操作できるようにするところから始めないと、脆弱性の解消どころか研究すら手が付けられないとしている。

    脆弱性を利用する方にとっても高度すぎて手を付けられないということになるなw

    • by t67ha3eb10zq (48523) on 2019年02月28日 19時11分 (#3572852)
      既存のデータを元にして、人に殆ど突けない惰弱性を機械の性能で突かせる事に成功したら
      、既存の構造では人間が機械を上回る事が不可能に成る可能性も出て来るね。
      もしかすると・・惰弱性の発見自体既に人の力では無い可能性も考えないと、手遅れに成るかも。
      親コメント
      • by Anonymous Coward

        ストーリーが誤字だらけのスラドで、コメントの誤字にいちいち突っ込むのも野暮だけど……。
        さすがにこの「惰弱性(だじゃくせい)」は見過ごせない。

    • by Anonymous Coward on 2019年02月28日 21時30分 (#3572935)

      「投機的実行におけるサイドチャネルを残したまま」
      対策を行ったり対策された状況での攻撃余地の探索についてはその通り。
      未対策の場合は普通に突けるだろうし。
      抜本対策(フェッチ段階で転かすとかコンテキストスイッチを厳密にやるとか)された場合は普通に余地が無くなるだろうし。

      前提を絞ってフィクションでの電子戦みたいな夢物語を現実として語ってみた感。

      親コメント
      • by Anonymous Coward

        > 抜本対策(フェッチ段階で転かすとかコンテキストスイッチを厳密にやるとか)された場合は普通に余地が無くなるだろうし。

        今のところハードウェア量が30-40%増えるか、互換性がなくなるかしか抜本策はないのだが?

    • by Anonymous Coward

      「適当にいじくったらカギがあいた。なんで開いたかは分からない」時、
      カギを直す側はどこから手を付けてイイかも分からないけれど、
      泥棒は盗みたい放題。

    • by Anonymous Coward

      つっても、x86_64, ARM, PowerPC...辺りの特に高性能組はもう十分頑健な実証コードがあるんだから、新しく見つける必要すらないんだけどな。

    • by Anonymous Coward

      ならないでしょ。「攻撃は簡単、防御は困難」ということ。
      投機的実行でCPUのパフォーマンスを向上させてきたけど、それがセキュリティとトレードオフの関係であることにずっと無自覚だった。
      だけど、投機的実行はあまりに複雑な処理なので解決が難しい、というわけよ。

  • by Anonymous Coward on 2019年02月28日 20時09分 (#3572896)

    禅問答みたいな物だもんな
    存在してるなら観測できる
    それを地で行って観測してアドレス拾ってくるし
    簡単に修正は無理ですよね

  • by Anonymous Coward on 2019年02月28日 20時18分 (#3572898)

    これからは「如何にSpectreの脆弱性に対策するか」ではなく「如何にSpectreを使うマルウェアの侵入を防ぐか」に焦点が移るのだろうか。

    • by Anonymous Coward

      同一の物理演算ユニットは同一権限のプロセス同士でしか使わせないとかで良いと思うよ。
      同一権限なら攻撃するまでもないんだから。

      • by Anonymous Coward on 2019年02月28日 22時38分 (#3572969)

        ブラウザのJavaScriptはブラウザの全データを読む権限が無いので、
        プロセスをタブ単位……どころか最悪js関数単位での分割が必要になったりして。

        あと、投機的実行中は本来読めないデータを読んで処理を進められるので、
        その実行痕跡を拾えば本来読めないデータが読めるってのもあった筈だが……
        こっちに関してはOSのデータ管理やシステムコールで何処までコンテキスト切り替えるかも弄ることになるんでは?

        親コメント
    • by Anonymous Coward

      つまり、「金庫を開けられないように対策」するのではなく、如何に「金庫にたどり着かせない」かになるということですね。
      そして、ドア等の進入経路を守っても鍵は壊される可能性がある。
      鍵を壊されるのを防げないなら、ドアが開いたことを検知できるようにして、セキュリティサービスを使う。
      そして、壁に穴を開けて侵入するという原始的な手法にヤラれてしまう・・・

      という風に、コンピュータセキュリティも永遠に商売ネタとして存続できそうですね。

  • by Anonymous Coward on 2019年02月28日 21時35分 (#3572938)

    理論屋の飯の種のためにいつまでもやってるとしか思えん

    • by Anonymous Coward

      現実問題として、一般のシステムでは雑多なスレッドが物理スレッドの何倍もの数で実行されているので、サイドチャネル攻撃のために狙ったスレッドと同じ物理Coreで同時に事項するということ自体が至難の業である。OSのスケジューラーを乗っ取るぐらいの権限を取得していなければ、有効な意味のある情報を取得することは事実上不可能だろう。

  • by Anonymous Coward on 2019年03月01日 0時34分 (#3573011)

    んですかね
    今後は性能を取って投機実行他をやめるか安全を取って続けるかの二択になるのかな
    CPUラインナップが2シリーズに分かれそう

  • by Anonymous Coward on 2019年03月01日 11時19分 (#3573175)

    これ系統の話をしていると必ず表題のような人が割り込んでくるんですが、本当なんでしょうか。
    問題ないのに騒いでるのはなぜなのでしょうか。騒いでるのはごく一部の変人なのでしょうか。
    私気になります。

    • by Anonymous Coward

      攻撃の被害を受ける可能性の話では間違っていないと思うけど。
      一方で緩和策の影響は現実として発生しているし、CPUアーキテクチャ等のパラダイムシフトでも起こればその影響は計り知れない。
      騒ぐのも然もありなん。

typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...