Intel CPUに脆弱性が発見される。64ビットOSや仮想化ソフトに影響 41
ストーリー by hylom
発見 部門より
発見 部門より
あるAnonymous Coward 曰く、
Intel CPUの「SYSRET」命令由来の脆弱性が発見された（Compuerworld、JVNVU）。
Intel CPU で動作する環境において、ring3 で実行されるプロセスは、細工されたスタックフレームを用意して、一般保護違反の発生時に ring0 で実行される (カーネル) プロセスに使用させることが可能です。
とのことで、この脆弱性を突くことで一般ユーザーが特権を取得したり、仮想化環境においてゲストOSからホストOSを操作される可能性があるという。なお、VMwareのハイパーバイザはこの命令を使用しないため問題は発生せず、またAMDプロセッサのSYSRET命令には問題がないとのこと。ただし、旧型のAMD CPUではこの攻撃を受けるとマシンがロックされる可能性があるとのこと。
仕様です (スコア:1)
これはIntel側としては、データシートに記載した仕様通りの動作です。
仕様を確認せずにAMDと完全互換のつもりでコードを書いた準仮想マシン側の不手際だし、
ましてやCPUの脆弱性などというものではありません。
仕様がAMDと完全互換ではないという点について
不備であるかどうかの意見は別にありますが、
AMDとIntelで完全互換だなんてことはありえないわけで、
仮想マシンを作る世界のレベルでそこを気にしないというのは、
言い訳のしようがないでしょう。
Re:仕様です (スコア:1, すばらしい洞察)
仕様として書かれているとしても、それがセキュリティホールになりうるものならば、仕様自体に欠陥があると言えるのではなかろうか？
# 仕様は読んでないけどさー
Re:仕様です (スコア:1)
Re:仕様です (スコア:1)
仕様通りだから何? 仕様に欠陥があるというだけのこと。.
客が仕様だといえばカラスが白いのも仕様であるという開発しかできない底辺コーダーの認識では「仕様の欠陥」など定義により存在しないのかもしれないけど。
Re:仕様です (スコア:1)
Re:仕様です (スコア:1)
部門名は「仕様だからしようがない」で
Re: (スコア:0)
「Microsoftのバグ」との戦い [nikkeibp.co.jp]ってやつですね。
Re: (スコア:0)
まぁだからどこもとっとと対応したんじゃない。
後出しで正論振りかざしたって君が偉くなった気になれるだけで何もいいことないよ。
Re: (スコア:0)
逆にAMDがSSEとかの命令の一部を微妙にバラバラに非互換にしたらCPUモデルの検出が必要になって
普及を進ませなくするという戦術も可能なわけですかね？
「ごめんちゃい、間違っちゃいました」と言ってしまったほうが賢いような…
Re: (スコア:0)
そういえば昔MMXの頃、AMDのMMXを認識できないソフトってあったよね。
確か、セガのPC版のバーチャロンがそうだったはず。
あれは… (スコア:0)
IntelのMMX使い方マニュアルにおいて、MMXが使用可能であるかを確かめる手順の
まず初めが「GPUIDでVenderIDが"GenuineIntel"であるか確かめる」になっていて
愚直にそのまま実装してしまうと、Intel以外のCPUではMMXが使えなくなり
あとからパッチをリリースしなくてはいけなくなるっていう罠じゃなかったかな？
なので、"GenuineIntel"の文字列（というか数値群）を"AuthenticAMD"とか
"CyrixInstead"とか"CentaurHauls"とか"RiseRiseRise"とかに書き換えたり、
文字列の一致チェック後の条件分岐命令（RETNZだったかな？）を
NOP（かそのCPUでしか使わないなら逆条件の分岐命令）に書き換えれば簡単に動くようになったはず
これを非互換といってしまうと、Intel製ではないのに"GenuineIntel"を名乗るしかないわけで
それはどうなんでしょうね
さらに古いの「NECO」「NECITSU」を思い出してしまうおっさんAC
Re: (スコア:0)
VenderIDでMMX等の拡張命令の有無がわかる訳でも無いのにそれを確認させるなんてねぇ。
Re: (スコア:0)
いや、違うベンダを想定した場合、MMX用に拡張した命令コードやフラグ情報を別の命令に使っているベンダが存在する可能性があります。だからマニュアル的にはベンダIDをチェックした上で拡張命令の存在をチェックする、としなければ不味いです。
無論、プログラム側ではサポートしうるすべてのCPUベンダ毎にそれぞれのベンダのマニュアルに応じた拡張命令の存在確認処理を行い演算ルーチンを切り替える必要があります。
ベンダIDチェックをスキップすることが可能なのは、サポートするすべてのCPUでベンダIDチェックを除き同じ方法でMMX拡張命令が使用可能で、かつ、サポートするCPUベンダ以外のCPUでは（暴走その他の危険を含むレベルでの）動作対象外とした場合のみです。
推奨環境以外でも最低限動くって事を意識した場合、ベンダIDチェックは必須です。
Re: (スコア:0)
この問題は、AMDがAMD-Vを発表した時に、当初から「AMDは」問題だとして指摘していた記憶がある。
その後、intelがVTを改訂していくなかで変更があったのかどうかは知らんけど。
あのさぁ・・・ (スコア:0)
どうやって対策すればいいの？
レンタルサーバとか詰みじゃない？
Re:あのさぁ・・・ (スコア:5, 参考になる)
Re:あのさぁ・・・ (スコア:3, 参考になる)
FreeBSD/amd64だとFreeBSD-SA-12:04.sysret [freebsd.org]で対応しています.
Re:あのさぁ・・・ (スコア:2)
レンタルサーバの公開スペックを確認して、
AMD系かARM系を選ぶとか。
VMwareは影響受けないみたいなので、
ESXi系で仮想化してるとこ探すとか。
2008R2/7/RedHat/Suse/FreeBSD/NetBSD辺りに
影響あるとなると大手はどれかに
引っかかるような気もしますけど
#安全なのはAMD+ESXi+Debian系とかかな・・・
#しかしAMDの旧型ってどこまでを指すんだろ？
Re:あのさぁ・・・ (スコア:1)
影響を受けるベンダーのほとんどは既にこの脆弱性を埋めるためのセキュリティ・パッチをリリースし、できるだけ早くパッチをインストールすることをユーザーに推奨している。米国Microsoftも6月12日に、この攻撃に関連するセキュリティ情報（MS12-042）を発表した。
Re: (スコア:0)
AMDの株を買おう！
Re: (スコア:0)
AMDの互換性は低い、という人が出てくる予感。
Re: (スコア:0)
「SYSRET」を使わない対策がされたKernelに上げれば済む話でしょ。
最近のCPUは勝手に最適化？とかして命令換えちゃうの？
Re: (スコア:0)
sysret実行時のrcxにnon canonical addressを渡すのが原因だから事前にチェックすればいいのでは？
Re:あのさぁ・・・ (スコア:1)
sysret実行時のrcxにnon canonical addressを渡すのが原因だから事前にチェックすればいいのでは？
そのnoncanonical addressのチェックタイミングが問題 [facebook.com]なのだが…
Re: (スコア:0)
sysret実行前にOS側でチェックしろと言ってるんだけど。
Re: (スコア:0)
OSってゲストの? マルウェアがいるかもしれない?
Re: (スコア:0)
それが簡単にできる状態なら、とっくに対策してると思うぞ。
（RCXはring3の仮想アドレスで、チェックするカーネルはring0で動いているんだから、MMUのアドレス変換／チェックロジックをソフトで実行して初めて確認できる。しかも、本来はリターン後にハードウェアが処理してくれるロジックだ）
そのコードを書くよりも、IRET命令で復帰する方が、実行サイクル的にも有利だから、結果的にIRETを使用するようにパッチが出ている。
＃そのせいで、Fast syscall/retのメリットが無くなるという本末転倒な話だが
Re: (スコア:0)
うちの使ってるレンタルサーバーは二週間ほど前に「まだ公開されていない脆弱性に対応するため緊急メンテするので30分程落とさせてもらいます」ってメールが来た。
多分対応済みのマシンにVMをイメージ毎移動させたんだと思う。
Re: (スコア:0)
本日の掃除スケジュール
サーバルーム：13:30～14:00
の可能性もあります。
Re: (スコア:0)
後出しで済まないが、複数台分のVMが移行されたのと、メンテ時間をこっちから指定もできたのでそれは無いと思う。
＃ネタなんだろうけど全然面白くなかったのでマジレス
Re: (スコア:0)
(#2176544)で書かれている記事 [facebook.com]によると
実は、Linux においてはこれと全く同じ原因の脆弱性が CVE-2006-0744 として登録され、5 年以上前に修正されていたのです。
との事なので、まだ公開されていない脆弱性って呼ぶのはどーなん
Re: (スコア:0)
マイクロコードのアップデートで何とでもなるんじゃない？
Re: (スコア:0)
Intel 64では「仕様」らしいので、SYSRET命令は実質的に使いものにならないので忘れてパフォーマンスの劣るIRETか、Intel独自のSYSEXIT使ってくださいってことになるんじゃね。
# まさかこんな手段でライバル仕様を葬るとはねえ
Re: (スコア:0)
Instruction Poisoningか
Re: (スコア:0)
2006年の時は、linux特有の問題だった CVE-2006-0744
不親切 (スコア:0)
この手のニュースの時にすべての物が対象なのかそれとも一部の製品にのみにあるのかはっきり書かれていないこと。
今回の場合もリンク先のニュースを読んでもx64対応のIntel CPUのすべてか特定のコアを採用した物かどうかの重要な部分が書かれていない。
>またAMDプロセッサのSYSRET命令には問題がないとのこと。ただし、旧型のAMD CPUではこの攻撃を受けるとマシンがロックされる可能性があるとのこと。
に関してもどこからが旧型なのか具体的に書かれていない。
リンク先のニュースだとxenやVMwareの商用系のは書かれているけど最近は普及度が上がってきているkvmはどうなのだろうか?
Re:不親切 (スコア:2)
"CVE-2012-0217 kvm"で google 検索すると，
> Every Xen and KVM user should update.
ってすぐに出てくるよ．いくつか条件があるけど，kvmも影響受ける可能性が高いです．更新しましょう．
Re: (スコア:0)
それって 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
RHELの対応状況 (スコア:0)
https://access.redhat.com/security/cve/CVE-2012-0217 [redhat.com]
Re: (スコア:0)
CVE-2012-0217に関していえば
RHEL5 だと kernel-xen-2.6.18 を使ってる人だけ影響を受けて Xen hypervisor の無い
kernel-2.6.18 であれば問題ないと考えて差し支えないのでしょうか？
OpenBSDは影響受けず (スコア:0)
さすがやでえ