アカウント名:
パスワード:
どうやって対策すればいいの?レンタルサーバとか詰みじゃない?
FreeBSD/amd64だとFreeBSD-SA-12:04.sysret [freebsd.org]で対応しています.
レンタルサーバの公開スペックを確認して、AMD系かARM系を選ぶとか。VMwareは影響受けないみたいなので、ESXi系で仮想化してるとこ探すとか。
2008R2/7/RedHat/Suse/FreeBSD/NetBSD辺りに影響あるとなると大手はどれかに引っかかるような気もしますけど
#安全なのはAMD+ESXi+Debian系とかかな・・・#しかしAMDの旧型ってどこまでを指すんだろ?
AMDの株を買おう!
AMDの互換性は低い、という人が出てくる予感。
「SYSRET」を使わない対策がされたKernelに上げれば済む話でしょ。最近のCPUは勝手に最適化?とかして命令換えちゃうの?
sysret実行時のrcxにnon canonical addressを渡すのが原因だから事前にチェックすればいいのでは?
そのnoncanonical addressのチェックタイミングが問題 [facebook.com]なのだが…
sysret実行前にOS側でチェックしろと言ってるんだけど。
OSってゲストの? マルウェアがいるかもしれない?
それが簡単にできる状態なら、とっくに対策してると思うぞ。(RCXはring3の仮想アドレスで、チェックするカーネルはring0で動いているんだから、MMUのアドレス変換/チェックロジックをソフトで実行して初めて確認できる。しかも、本来はリターン後にハードウェアが処理してくれるロジックだ)
そのコードを書くよりも、IRET命令で復帰する方が、実行サイクル的にも有利だから、結果的にIRETを使用するようにパッチが出ている。
#そのせいで、Fast syscall/retのメリットが無くなるという本末転倒な話だが
うちの使ってるレンタルサーバーは二週間ほど前に「まだ公開されていない脆弱性に対応するため緊急メンテするので30分程落とさせてもらいます」ってメールが来た。
多分対応済みのマシンにVMをイメージ毎移動させたんだと思う。
本日の掃除スケジュールサーバルーム:13:30~14:00
の可能性もあります。
後出しで済まないが、複数台分のVMが移行されたのと、メンテ時間をこっちから指定もできたのでそれは無いと思う。
#ネタなんだろうけど全然面白くなかったのでマジレス
(#2176544)で書かれている記事 [facebook.com]によると
実は、Linux においてはこれと全く同じ原因の脆弱性が CVE-2006-0744 として登録され、5 年以上前に修正されていたのです。
との事なので、まだ公開されていない脆弱性って呼ぶのはどーなん
マイクロコードのアップデートで何とでもなるんじゃない?
Intel 64では「仕様」らしいので、SYSRET命令は実質的に使いものにならないので忘れてパフォーマンスの劣るIRETか、Intel独自のSYSEXIT使ってくださいってことになるんじゃね。# まさかこんな手段でライバル仕様を葬るとはねえ
Instruction Poisoningか
2006年の時は、linux特有の問題だった CVE-2006-0744
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
あのさぁ・・・ (スコア: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