パスワードを忘れた? アカウント作成
4291902 story
バグ

Intel CPUに脆弱性が発見される。64ビットOSや仮想化ソフトに影響 41

ストーリー by hylom
発見 部門より
あるAnonymous Coward 曰く、

Intel CPUの「SYSRET」命令由来の脆弱性が発見された(CompuerworldJVNVU)。

Intel CPU で動作する環境において、ring3 で実行されるプロセスは、細工されたスタックフレームを用意して、一般保護違反の発生時に ring0 で実行される (カーネル) プロセスに使用させることが可能です。

とのことで、この脆弱性を突くことで一般ユーザーが特権を取得したり、仮想化環境においてゲストOSからホストOSを操作される可能性があるという。なお、VMwareのハイパーバイザはこの命令を使用しないため問題は発生せず、またAMDプロセッサのSYSRET命令には問題がないとのこと。ただし、旧型のAMD CPUではこの攻撃を受けるとマシンがロックされる可能性があるとのこと。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2012年06月19日 12時59分 (#2176332)

    これはIntel側としては、データシートに記載した仕様通りの動作です。
    仕様を確認せずにAMDと完全互換のつもりでコードを書いた準仮想マシン側の不手際だし、
    ましてやCPUの脆弱性などというものではありません。

    仕様がAMDと完全互換ではないという点について
    不備であるかどうかの意見は別にありますが、
    AMDとIntelで完全互換だなんてことはありえないわけで、
    仮想マシンを作る世界のレベルでそこを気にしないというのは、
    言い訳のしようがないでしょう。

    • Re:仕様です (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2012年06月19日 13時09分 (#2176340)

      仕様として書かれているとしても、それがセキュリティホールになりうるものならば、仕様自体に欠陥があると言えるのではなかろうか?

      # 仕様は読んでないけどさー

      親コメント
    • by Anonymous Coward on 2012年06月19日 13時55分 (#2176387)

      仕様通りだから何? 仕様に欠陥があるというだけのこと。.
      客が仕様だといえばカラスが白いのも仕様であるという開発しかできない底辺コーダーの認識では「仕様の欠陥」など定義により存在しないのかもしれないけど。

      親コメント
    • by Anonymous Coward

      まぁだからどこもとっとと対応したんじゃない。
      後出しで正論振りかざしたって君が偉くなった気になれるだけで何もいいことないよ。

    • by Anonymous Coward

      逆にAMDがSSEとかの命令の一部を微妙にバラバラに非互換にしたらCPUモデルの検出が必要になって
      普及を進ませなくするという戦術も可能なわけですかね?
      「ごめんちゃい、間違っちゃいました」と言ってしまったほうが賢いような…

      • by Anonymous Coward

        そういえば昔MMXの頃、AMDのMMXを認識できないソフトってあったよね。
        確か、セガのPC版のバーチャロンがそうだったはず。

        • by Anonymous Coward

          IntelのMMX使い方マニュアルにおいて、MMXが使用可能であるかを確かめる手順の
          まず初めが「GPUIDでVenderIDが"GenuineIntel"であるか確かめる」になっていて
          愚直にそのまま実装してしまうと、Intel以外のCPUではMMXが使えなくなり
          あとからパッチをリリースしなくてはいけなくなるっていう罠じゃなかったかな?

          なので、"GenuineIntel"の文字列(というか数値群)を"AuthenticAMD"とか
          "CyrixInstead"とか"CentaurHauls"とか"RiseRiseRise"とかに書き換えたり、
          文字列の一致チェック後の条件分岐命令(RETNZだったかな?)を
          NOP(かそのCPUでしか使わないなら逆条件の分岐命令)に書き換えれば簡単に動くようになったはず

          これを非互換といってしまうと、Intel製ではないのに"GenuineIntel"を名乗るしかないわけで
          それはどうなんでしょうね

          さらに古いの「NECO」「NECITSU」を思い出してしまうおっさんAC

          • by Anonymous Coward

            VenderIDでMMX等の拡張命令の有無がわかる訳でも無いのにそれを確認させるなんてねぇ。

          • by Anonymous Coward

            いや、違うベンダを想定した場合、MMX用に拡張した命令コードやフラグ情報を別の命令に使っているベンダが存在する可能性があります。だからマニュアル的にはベンダIDをチェックした上で拡張命令の存在をチェックする、としなければ不味いです。
            無論、プログラム側ではサポートしうるすべてのCPUベンダ毎にそれぞれのベンダのマニュアルに応じた拡張命令の存在確認処理を行い演算ルーチンを切り替える必要があります。
            ベンダIDチェックをスキップすることが可能なのは、サポートするすべてのCPUでベンダIDチェックを除き同じ方法でMMX拡張命令が使用可能で、かつ、サポートするCPUベンダ以外のCPUでは(暴走その他の危険を含むレベルでの)動作対象外とした場合のみです。

            推奨環境以外でも最低限動くって事を意識した場合、ベンダIDチェックは必須です。

    • by Anonymous Coward

      この問題は、AMDがAMD-Vを発表した時に、当初から「AMDは」問題だとして指摘していた記憶がある。
      その後、intelがVTを改訂していくなかで変更があったのかどうかは知らんけど。

  • by Anonymous Coward on 2012年06月19日 11時53分 (#2176272)

    どうやって対策すればいいの?
    レンタルサーバとか詰みじゃない?

    • by thorin (14200) on 2012年06月19日 12時09分 (#2176294)
      XEN とかは SYSRET を他の命令(IRET)で代替するパッチが出ているので(カーネルでなくて)ハイパーバイザーの方をアップデートしてください。
      親コメント
    • by SteppingWind (2654) on 2012年06月19日 14時01分 (#2176399)

      FreeBSD/amd64だとFreeBSD-SA-12:04.sysret [freebsd.org]で対応しています.

      親コメント
    • by akairaiden (11916) on 2012年06月19日 12時11分 (#2176296) 日記

      レンタルサーバの公開スペックを確認して、
      AMD系かARM系を選ぶとか。
      VMwareは影響受けないみたいなので、
      ESXi系で仮想化してるとこ探すとか。

      2008R2/7/RedHat/Suse/FreeBSD/NetBSD辺りに
      影響あるとなると大手はどれかに
      引っかかるような気もしますけど

      #安全なのはAMD+ESXi+Debian系とかかな・・・
      #しかしAMDの旧型ってどこまでを指すんだろ?

      親コメント
    • by adeu (2937) on 2012年06月19日 12時02分 (#2176287)
      ComputerWorldの翻訳記事に書いてますよ。

      影響を受けるベンダーのほとんどは既にこの脆弱性を埋めるためのセキュリティ・パッチをリリースし、できるだけ早くパッチをインストールすることをユーザーに推奨している。米国Microsoftも6月12日に、この攻撃に関連するセキュリティ情報(MS12-042)を発表した。
      親コメント
    • by Anonymous Coward

      AMDの株を買おう!

      • by Anonymous Coward

        AMDの互換性は低い、という人が出てくる予感。

    • by Anonymous Coward

      「SYSRET」を使わない対策がされたKernelに上げれば済む話でしょ。
      最近のCPUは勝手に最適化?とかして命令換えちゃうの?

    • by Anonymous Coward

      sysret実行時のrcxにnon canonical addressを渡すのが原因だから事前にチェックすればいいのでは?

      • by Anonymous Coward on 2012年06月19日 16時40分 (#2176544)

        sysret実行時のrcxにnon canonical addressを渡すのが原因だから事前にチェックすればいいのでは?

        そのnoncanonical addressのチェックタイミングが問題 [facebook.com]なのだが…

        親コメント
        • by Anonymous Coward

          sysret実行前にOS側でチェックしろと言ってるんだけど。

          • by Anonymous Coward

            OSってゲストの? マルウェアがいるかもしれない?

          • by Anonymous Coward

            それが簡単にできる状態なら、とっくに対策してると思うぞ。
            (RCXはring3の仮想アドレスで、チェックするカーネルはring0で動いているんだから、MMUのアドレス変換/チェックロジックをソフトで実行して初めて確認できる。しかも、本来はリターン後にハードウェアが処理してくれるロジックだ)

            そのコードを書くよりも、IRET命令で復帰する方が、実行サイクル的にも有利だから、結果的にIRETを使用するようにパッチが出ている。

            #そのせいで、Fast syscall/retのメリットが無くなるという本末転倒な話だが

    • by Anonymous Coward

      うちの使ってるレンタルサーバーは二週間ほど前に「まだ公開されていない脆弱性に対応するため緊急メンテするので30分程落とさせてもらいます」ってメールが来た。

      多分対応済みのマシンにVMをイメージ毎移動させたんだと思う。

      • by Anonymous Coward

        本日の掃除スケジュール
        サーバルーム:13:30~14:00

        の可能性もあります。

        • by Anonymous Coward

          後出しで済まないが、複数台分のVMが移行されたのと、メンテ時間をこっちから指定もできたのでそれは無いと思う。

          #ネタなんだろうけど全然面白くなかったのでマジレス

      • by Anonymous Coward

        (#2176544)で書かれている記事 [facebook.com]によると

        実は、Linux においてはこれと全く同じ原因の脆弱性が CVE-2006-0744 として登録され、5 年以上前に修正されていたのです。

        との事なので、まだ公開されていない脆弱性って呼ぶのはどーなん

    • by Anonymous Coward

      マイクロコードのアップデートで何とでもなるんじゃない?

      • by Anonymous Coward

        Intel 64では「仕様」らしいので、SYSRET命令は実質的に使いものにならないので忘れてパフォーマンスの劣るIRETか、Intel独自のSYSEXIT使ってくださいってことになるんじゃね。
        # まさかこんな手段でライバル仕様を葬るとはねえ

    • by Anonymous Coward

      2006年の時は、linux特有の問題だった CVE-2006-0744

  • by Anonymous Coward on 2012年06月19日 12時20分 (#2176302)

    この手のニュースの時にすべての物が対象なのかそれとも一部の製品にのみにあるのかはっきり書かれていないこと。
    今回の場合もリンク先のニュースを読んでもx64対応のIntel CPUのすべてか特定のコアを採用した物かどうかの重要な部分が書かれていない。

    >またAMDプロセッサのSYSRET命令には問題がないとのこと。ただし、旧型のAMD CPUではこの攻撃を受けるとマシンがロックされる可能性があるとのこと。
    に関してもどこからが旧型なのか具体的に書かれていない。

    リンク先のニュースだとxenやVMwareの商用系のは書かれているけど最近は普及度が上がってきているkvmはどうなのだろうか?

    • by annoymouse coward (11178) on 2012年06月19日 12時41分 (#2176314) 日記

      "CVE-2012-0217 kvm"で google 検索すると,

      > Every Xen and KVM user should update.

      ってすぐに出てくるよ.いくつか条件があるけど,kvmも影響受ける可能性が高いです.更新しましょう.

      親コメント
      • by Anonymous Coward

        それって  KVM and Xen 6400 [novell.com] のことですよね。

        これはきちんと読むと書いてありますが、CVE-2012-0217を含む複数の脆弱性に対する一括アップデートであって、CVE-2012-0217単体の修正ではありません。

        また、 kvmメーリングリスト [spinics.net] でも、

        Xen is only vulnerable with paravirtualized guests. KVM only support
        hardware-assisted virtualization.

        The Linux kernel that is used by KVM used to have similar
        vulnerabilities, but they were fixed a long time ag

  • by Anonymous Coward on 2012年06月19日 15時39分 (#2176476)
    • by Anonymous Coward

      CVE-2012-0217に関していえば
      RHEL5 だと kernel-xen-2.6.18 を使ってる人だけ影響を受けて Xen hypervisor の無い
      kernel-2.6.18 であれば問題ないと考えて差し支えないのでしょうか?

  • by Anonymous Coward on 2012年06月20日 10時55分 (#2177106)

    さすがやでえ

typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

読み込み中...