アカウント名:
パスワード:
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に悪意のあるコードを流し込む点にあります．
しかし彼の方法でコードが流し込めるのはNehalemまでで，sandy bridge 以降ではCPUの挙動が変わったのでコードが流し込めないとのことです．
SMRAM に悪意のあるコードを流し込む概念は既出で、今回はそれの新しい方法っぽいな。
APIC に特別な割り込みがかかった場合に、 SMRAM として確保された領域のコードが実行される。この領域はBIOS実行時にROMから割り込みハンドラがコピーしてあって、ring -2 でのみアクセスできる。 ring -1(VMX root) ですら読み書きできないので、油断して色々と書いてある。しかし、x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で、ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる。一旦この割り込みハンドラに任意コードを書いておけば、実際に割り込みが発生した時にロングジャンプするなりして好きなコードを実行できる。この時 CPU が入っている ring -2 という超特権モードでは、CPU のセキュリティ機能の一部もスルーできる。
SMRAM は CPU から見えるメモリの一部を指定しているだけで、そういうメモリ素子があるわけではない。だから、電源を抜いてから信頼できる ROM から起動すれば、消える。
デタラメな要約ですね。
> x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で今回利用したのはCPU内の割り込みコンロトーラ(Local APIC)のレジスタ領域をSMRAM上に被せたのであってメモリのリマップ機能は使っていない。
> ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる書き換えたのはring 0で書き換える事ができるLocal APICレジスタ。レジスタに書き込んだ値を命令として実行させようとしたが、実際に効果があるのはデータアクセスだけで命令読み込みはSMRAMから読み込まれてしまい失敗。しかし、Locl APICレジスタ被せでGDTのアドレス計算元のデータが書き換えられて運良くring -2の処理で使用するGDTがSMRAM外のring 0で書き換え可能な領域に飛び出す事を見つけたのでring -2のまま任意の場所にジャンプさせる事に成功。
こんな感じですかね。最初にring 0を取らないといけないのがハードル高いですが、やられたら面倒かな。
このコメントを見ると元コメントは正確ではないと予測はできるけど、出鱈目というほど間違っても居ないと思う。
> メモリのリマップ機能は使っていない。汎用のメモリ空間を扱うためのリマップ機能ではないけれど、レジスタ領域のマッピングを被せてるんなら大差ないと思う。
> レジスタ被せで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の操作である、と。
ねーよ
わかるようなわからないような。
Local APICのMMIO用のマッピング場所はRing 0でほいほい移動できるものなんですか？
> ring -2の処理で使用するGDTがSMRAM外のring 0で書き換え可能な領域に飛び出すここが諸悪の根源という理解でいいんでしょうか。
#2863684ですが、なんとなく雰囲気はわかってきました。
1. APICレジスタはメモリアドレス0に固定されている2. APICレジスタの中にSSMのSMIがあるから、やっぱり固定されている3. LAPICをメモリアドレスSSM関連データ構造部分にリマップできる。4. (3)の状態だと、該当部分のREADはメモリからではなくLAPICレジスタから読んでしまう。5. SMMのエントリポイントは、途中でGDTをセットするが、この値もLAPICでごまかせる（？）6. いい感じにジャンプ命令もあるからRong -2で好きな所に移動できる。
GDTのからみはあってるのかよく分からない…
1と6は微妙ですが流れとしてはあってます
ありがとうございます。
割込み禁止にしていたずらすれば、該当CPUスレッドのカーネルがLAPICレジスタを触ることも無いような気がするので、気づかれずに済ますこともそんなに難しくないのかな…。
たまにこういう話もできると個人的に楽しいですね。
突っ込んだら負け？
タレコミにリンクのあるengadgetの記事> CPU そのものに仕込まれるため、ユーザーが OS をクリーンインストールしなおしても感染は取り除けず、> UEFI/BIOS をすべてクリアしても何の意味もありません。
# 誰がどこにそのプログラムを仕込むんだよ
色々と面倒だから、Intelのマニュアルを読むのを勧める程度で。
あなたが読み直してみた方がいいのでは？IntelのCPUにはNVRAMは乗ってない。OTPメモリはあるみたいだけど、パッケージのピンには出てない。
engadgetの記事を信用すると、CPU内に不揮発性RAMがあるって話になっちゃうよ…
マイクロコードのアップデートさえ外から読み込むのに、そんな不揮発性RAM持っているって話自体信用ならない気が
engadgetの記事が間違ってる。
>ring -2 でのみアクセスできる。 ring -1(VMX root) ですら読み書きできないので
こんな場所あるのか？
それがSMRAM
> SMRAM に悪意のあるコードを流し込む概念は既出
どれくらい既出かというと、ITproの記事 [nikkeibp.co.jp]によるとなんと2006年にはすでにSMMを使ったRootkitの可能性が指摘されて、2008年にはコンセプトが存在したようだ。今年の3月 [jvn.jp]にもSMMがらみの脆弱性が報告されてるし、ぜんぜん「忘れ去られた」ってレベルじゃないな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
sandy bridge 以降は大丈夫? (スコア:1)
Re:sandy bridge 以降は大丈夫? (スコア: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に悪意のあるコードを流し込む点にあります．
しかし彼の方法でコードが流し込めるのはNehalemまでで，
sandy bridge 以降ではCPUの挙動が変わったのでコードが流し込めないとのことです．
Re:sandy bridge 以降は大丈夫? (スコア:5, 参考になる)
SMRAM に悪意のあるコードを流し込む概念は既出で、今回はそれの新しい方法っぽいな。
APIC に特別な割り込みがかかった場合に、 SMRAM として確保された領域のコードが実行される。この領域はBIOS実行時にROMから割り込みハンドラがコピーしてあって、ring -2 でのみアクセスできる。 ring -1(VMX root) ですら読み書きできないので、油断して色々と書いてある。しかし、x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で、ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる。一旦この割り込みハンドラに任意コードを書いておけば、実際に割り込みが発生した時にロングジャンプするなりして好きなコードを実行できる。この時 CPU が入っている ring -2 という超特権モードでは、CPU のセキュリティ機能の一部もスルーできる。
SMRAM は CPU から見えるメモリの一部を指定しているだけで、そういうメモリ素子があるわけではない。だから、電源を抜いてから信頼できる ROM から起動すれば、消える。
Re:sandy bridge 以降は大丈夫? (スコア:1)
デタラメな要約ですね。
> x86_64 には様々なメモリのリマップ機能があって、何かをそのセキュア領域にマッピングした上で
今回利用したのはCPU内の割り込みコンロトーラ(Local APIC)のレジスタ領域をSMRAM上に被せたのであって
メモリのリマップ機能は使っていない。
> ring 0 権限のみの操作に見せかけて、制限をスルーして書き込むことができる
書き換えたのはring 0で書き換える事ができるLocal APICレジスタ。レジスタに書き込んだ値を命令として実行さ
せようとしたが、実際に効果があるのはデータアクセスだけで命令読み込みはSMRAMから読み込まれてしまい失敗。
しかし、Locl APICレジスタ被せでGDTのアドレス計算元のデータが書き換えられて運良くring -2の処理で使用する
GDTがSMRAM外のring 0で書き換え可能な領域に飛び出す事を見つけたのでring -2のまま任意の場所にジャンプさ
せる事に成功。
こんな感じですかね。
最初にring 0を取らないといけないのがハードル高いですが、やられたら面倒かな。
Re: (スコア:0)
このコメントを見ると元コメントは正確ではないと予測はできるけど、出鱈目というほど間違っても居ないと思う。
> メモリのリマップ機能は使っていない。
汎用のメモリ空間を扱うためのリマップ機能ではないけれど、
レジスタ領域のマッピングを被せてるんなら大差ないと思う。
> レジスタ被せでGDTのアドレス計算元のデータが書き換えられて
> ring 0で書き換え可能な領域に飛び出す
コレのことでは？
> 最初にring 0を取らないといけないのがハードル高いですが、やられたら面倒かな。
カーネル(ゲストOSでも良い？)まで食われた場合に被害が増えるかも的な感じですね。
ゲストOSからの昇格だと厄介だけど、ホストOSの場合そこまで食われてる時点もうね…
Re: (スコア:0)
細かい事はどうでもいいという人には同じような物かもしれませんが、残念ながら全くデタラメです。
肝心のring 0 権限のみの操作に見せかけて、制限をスルーして書き込むなんて事はやってません。
Re: (スコア:0)
「ring 0権限で、ring 0では書き込む権限のない領域を書き換える」
と
「ring 0 権限のみの操作に見せかけて、制限をスルーして書き込む」
にどれほどの違いがあるのか詳しくお願いします。
制限されてるのに書き換えられたんだから制限をスルーしてるじゃないか。
Re: (スコア:0)
ring 0ではring 0の制限でできる事をやっているのでどちらの表現も間違っています
Re: (スコア:0)
あー、あれか。「バグじゃない、仕様です」って話なのか。
結果としてring 0で適応「されるべき」制限を一部回避してるわけだけど、
ring 0で実行「できてる」以上それはring 0の操作である、と。
ねーよ
Re: (スコア:0)
わかるようなわからないような。
Local APICのMMIO用のマッピング場所は
Ring 0でほいほい移動できるものなんですか？
> ring -2の処理で使用するGDTがSMRAM外のring 0で書き換え可能な領域に飛び出す
ここが諸悪の根源という理解でいいんでしょうか。
Re: (スコア:0)
#2863684ですが、なんとなく雰囲気はわかってきました。
1. APICレジスタはメモリアドレス0に固定されている
2. APICレジスタの中にSSMのSMIがあるから、やっぱり固定されている
3. LAPICをメモリアドレスSSM関連データ構造部分にリマップできる。
4. (3)の状態だと、該当部分のREADはメモリからではなくLAPICレジスタから読んでしまう。
5. SMMのエントリポイントは、途中でGDTをセットするが、この値もLAPICでごまかせる（？）
6. いい感じにジャンプ命令もあるからRong -2で好きな所に移動できる。
GDTのからみはあってるのかよく分からない…
Re: (スコア:0)
1と6は微妙ですが流れとしてはあってます
Re: (スコア:0)
ありがとうございます。
割込み禁止にしていたずらすれば、
該当CPUスレッドのカーネルがLAPICレジスタを触ることも
無いような気がするので、気づかれずに済ますこともそんなに難しくないのかな…。
たまにこういう話もできると個人的に楽しいですね。
Re: (スコア:0)
突っ込んだら負け？
タレコミにリンクのあるengadgetの記事
> CPU そのものに仕込まれるため、ユーザーが OS をクリーンインストールしなおしても感染は取り除けず、
> UEFI/BIOS をすべてクリアしても何の意味もありません。
# 誰がどこにそのプログラムを仕込むんだよ
Re:sandy bridge 以降は大丈夫? (スコア:2)
色々と面倒だから、Intelのマニュアルを読むのを勧める程度で。
Re: (スコア:0)
あなたが読み直してみた方がいいのでは？
IntelのCPUにはNVRAMは乗ってない。
OTPメモリはあるみたいだけど、パッケージのピンには出てない。
Re: (スコア:0)
engadgetの記事を信用すると、CPU内に不揮発性RAMがあるって話になっちゃうよ…
マイクロコードのアップデートさえ外から読み込むのに、そんな不揮発性RAM持っているって話自体信用ならない気が
Re: (スコア:0)
engadgetの記事が間違ってる。
Re: (スコア:0)
>ring -2 でのみアクセスできる。 ring -1(VMX root) ですら読み書きできないので
こんな場所あるのか？
Re: (スコア:0)
それがSMRAM
Re: (スコア:0)
> SMRAM に悪意のあるコードを流し込む概念は既出
どれくらい既出かというと、ITproの記事 [nikkeibp.co.jp]によるとなんと2006年にはすでにSMMを使ったRootkitの可能性が指摘されて、2008年にはコンセプトが存在したようだ。
今年の3月 [jvn.jp]にもSMMがらみの脆弱性が報告されてるし、ぜんぜん「忘れ去られた」ってレベルじゃないな。