アカウント名:
パスワード:
sandy bridge 以降は，今のところ大丈夫です
blackhat.com に論文と発表スライドが，github.com に実証コードが upload されています https://www.blackhat.com/us-15/speakers/Christopher-Domas.html [blackhat.com] https://github.com/xoreaxeaxeax/sinkhole [github.com]
ざっと目を通した感じではこのアタック方法の肝は，APICのレジスタをメモリマッピングする仕組みを悪用してSMRAMに悪意のあるコードを流し込
SMRAM に悪意のあるコードを流し込む概念は既出で、今回はそれの新しい方法っぽいな。
APIC に特別な割り込みがかかった場合に、 SMRAM として確保された領域のコードが実行される。この領域はBIOS実行時にROMから割り込みハンドラがコピーしてあって、ring -2 でのみアクセスできる。 ring -1(VMX root) ですら読み書きできないので、油断して色々と書いてある。しかし、x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で、ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる。一
デタラメな要約ですね。
> x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で今回利用したのはCPU内の割り込みコンロトーラ(Local APIC)のレジスタ領域をSMRAM上に被せたのであってメモリのリマップ機能は使っていない。
> ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる書き換えたのはring 0で書き換える事ができるLocal APICレジスタ。レジスタに書き込んだ値を命令として実行させようとしたが、実際に効果があるのはデータアクセスだけで命令読み込みはSMRAMか
このコメントを見ると元コメントは正確ではないと予測はできるけど、出鱈目というほど間違っても居ないと思う。
> メモリのリマップ機能は使っていない。汎用のメモリ空間を扱うためのリマップ機能ではないけれど、レジスタ領域のマッピングを被せてるんなら大差ないと思う。
> レジスタ被せでGDTのアドレス計算元のデータが書き換えられて> ring 0で書き換え可能な領域に飛び出すコレのことでは？
> 最初にring 0を取らないといけないのがハードル高いですが、やられたら面倒かな。カーネル(ゲストOSでも良い？)まで食われた場合に被害が増えるかも的な感じですね。ゲストOSからの昇格だと厄介だけど、ホストOSの場合そこまで食われてる時点もうね…
細かい事はどうでもいいという人には同じような物かもしれませんが、残念ながら全くデタラメです。肝心のring 0 権限のみの操作に見せかけて、制限をスルーして書き込むなんて事はやってません。
「ring 0権限で、ring 0では書き込む権限のない領域を書き換える」と「ring 0 権限のみの操作に見せかけて、制限をスルーして書き込む」にどれほどの違いがあるのか詳しくお願いします。制限されてるのに書き換えられたんだから制限をスルーしてるじゃないか。
ring 0ではring 0の制限でできる事をやっているのでどちらの表現も間違っています
あー、あれか。「バグじゃない、仕様です」って話なのか。結果としてring 0で適応「されるべき」制限を一部回避してるわけだけど、ring 0で実行「できてる」以上それはring 0の操作である、と。
ねーよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
sandy bridge 以降は大丈夫? (スコア:1)
Re: (スコア:5, 参考になる)
sandy bridge 以降は，今のところ大丈夫です
blackhat.com に論文と発表スライドが，github.com に実証コードが upload されています
https://www.blackhat.com/us-15/speakers/Christopher-Domas.html [blackhat.com]
https://github.com/xoreaxeaxeax/sinkhole [github.com]
ざっと目を通した感じでは
このアタック方法の肝は，APICのレジスタをメモリマッピングする仕組みを悪用して
SMRAMに悪意のあるコードを流し込
Re: (スコア:5, 参考になる)
SMRAM に悪意のあるコードを流し込む概念は既出で、今回はそれの新しい方法っぽいな。
APIC に特別な割り込みがかかった場合に、 SMRAM として確保された領域のコードが実行される。この領域はBIOS実行時にROMから割り込みハンドラがコピーしてあって、ring -2 でのみアクセスできる。 ring -1(VMX root) ですら読み書きできないので、油断して色々と書いてある。しかし、x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で、ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる。一
Re: (スコア:1)
デタラメな要約ですね。
> x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で
今回利用したのはCPU内の割り込みコンロトーラ(Local APIC)のレジスタ領域をSMRAM上に被せたのであって
メモリのリマップ機能は使っていない。
> ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる
書き換えたのはring 0で書き換える事ができるLocal APICレジスタ。レジスタに書き込んだ値を命令として実行さ
せようとしたが、実際に効果があるのはデータアクセスだけで命令読み込みはSMRAMか
Re: (スコア:0)
このコメントを見ると元コメントは正確ではないと予測はできるけど、出鱈目というほど間違っても居ないと思う。
> メモリのリマップ機能は使っていない。
汎用のメモリ空間を扱うためのリマップ機能ではないけれど、
レジスタ領域のマッピングを被せてるんなら大差ないと思う。
> レジスタ被せでGDTのアドレス計算元のデータが書き換えられて
> ring 0で書き換え可能な領域に飛び出す
コレのことでは？
> 最初にring 0を取らないといけないのがハードル高いですが、やられたら面倒かな。
カーネル(ゲストOSでも良い？)まで食われた場合に被害が増えるかも的な感じですね。
ゲストOSからの昇格だと厄介だけど、ホストOSの場合そこまで食われてる時点もうね…
Re: (スコア:0)
細かい事はどうでもいいという人には同じような物かもしれませんが、残念ながら全くデタラメです。
肝心のring 0 権限のみの操作に見せかけて、制限をスルーして書き込むなんて事はやってません。
Re:sandy bridge 以降は大丈夫? (スコア:0)
「ring 0権限で、ring 0では書き込む権限のない領域を書き換える」
と
「ring 0 権限のみの操作に見せかけて、制限をスルーして書き込む」
にどれほどの違いがあるのか詳しくお願いします。
制限されてるのに書き換えられたんだから制限をスルーしてるじゃないか。
Re: (スコア:0)
ring 0ではring 0の制限でできる事をやっているのでどちらの表現も間違っています
Re: (スコア:0)
あー、あれか。「バグじゃない、仕様です」って話なのか。
結果としてring 0で適応「されるべき」制限を一部回避してるわけだけど、
ring 0で実行「できてる」以上それはring 0の操作である、と。
ねーよ