ASLR を簡単に回避する方法が公開される 22
ストーリー by reo
weasel 部門より
weasel 部門より
ある Anonymous Coward 曰く、
KingCope というハッカーが Windows 7, 8 で ASLR を回避する方法を公開した (kingcopes´ blag の記事、本家 /. 記事より) 。
ASLR とは exe データやモジュールの読み込み位置をランダム化して、クラッキングを困難にする技術。2001 年に PaX という Linux 向けセキュリティパッチとしてリリースされました。Windows 8 または更新プログラムを適用した Windows 7 では ASLR が確実に適用されるように強制することができますが (参考: フォティーンフォティ技術研究所の資料 [PDF])、アプリの互換性の低下として様々なデメリットも表面化しているようです。簡単に回避できるならアプリ互換性をとったほうが良かったのでしょうか? それとも多少は (古いウィルスには) 効果があるので良かったのでしょうか?
元記事を読んでみた。 (スコア:4, 参考になる)
ざっと読んだ感じだと、割り当てられなくなるまでヒープを要求して、割り当てられなくなったら、そのヒープの領域をひたすら適当なデータで埋めて、それが終わったら、ちょろっと開放して DLL をロードすれば、その DLL はちょろっと開放した領域にロードされるから、後はそのちょろっと開放した時の範囲でヒープスプレーをして、目的の物を見つけ出して呼び出す、といった感じかな？
ひたすらヒープを埋める時には、
といった具合に、ほぼ DoS 状態になると思うけど、「なんか激重になったなぁ」と思ってプログラムを強制終了されたら、シェルコードの実行まではたどり着かないんじゃないかなぁ。特に 64bit 版だったりしたら、かなり時間もかかりそうだし。
Re: (スコア:0)
時間よりもメモリを使い切って死ぬ
Re: (スコア:0)
Windows8だと強制終了できないときが多い
50%くらいの確率でタスクマネージャーやProcessExplorerから強制終了してもゾンビプロセスが残って強制終了できない
簡単に回避できるかいまいち不明 (スコア:3, 参考になる)
どうも、この方法って乱暴に言うと「ASLRは空きメモリの中で実行コードの読み込み位置をランダム化して攻撃を避けやすくする。なら、空きメモリを減らしてやりゃあ、読み込み位置は1つに決まっちゃうんじゃね？モグラ叩きでモグラ穴を1個残して埋めてやりゃあ、確実にその穴からモグラが顔を出すみたいに」という方法みたいですね。
で、本家の方では「実証は32bitでやってるけど、64bitだと埋めなきゃいけないメモリが広すぎて機能しないんじゃね？」みたいな話が挙がってます。
元々ASLRって、繰り返し攻撃できる状態ならまぐれ当たりの確率が上がっていくので確実な防御ではないはずですよね。その程度のものを突破するためにメモリを急激に大量消費するってのは、発覚するリスクとか考えると「簡単に回避」でもないような気がします。
元ネタの英文とか斜め読みなので認識が間違ってるかもしれませんけど。
Re: (スコア:0)
何というか、この手法は指摘されるまでもなくMSも認識してたはずです。
64bitのアドレス空間を埋め尽くすのは現実的で無いため問題ないとの認識も。
32bitシステムでは問題になりますけど…
Re:簡単に回避できるかいまいち不明 (スコア:1)
拡張保護モード [msdn.com]の解説でふれていました。
攻撃者が悪意のあるコードを予測可能な位置に植え付ける手段としては Heap Spray (英語) 攻撃がありますが、64 ビットのアドレス空間を "埋め尽くす" ことは現実的でないため、この攻撃が成功する可能性は大幅に低下します。相当範囲のアドレス空間に攻撃が及ぶよりも先に、メモリとディスク領域の方が不足するでしょう
Re: (スコア:0)
予約(MEM_RESERVE)するだけなら物理メモリもディスク領域も使わないはずなんだがなあ。
Re:簡単に回避できるかいまいち不明 (スコア:1)
本家の (#42697175) [slashdot.org]がまさにその辺りの議論ですな。
「その通り。それで、ブラウザ上のJavaScriptからそれを行えるかね？
JavaScriptにはメモリを予約する関数も low level binding もないのさ。実際にメモリを確保する(MEM_COMMIT)ことしかできないんだ。で、ライブラリの読み込み位置を予測できるだけのメモリを確保するずっと前に、コミット制限に引っかかるだろう。
結局のところ、元記事の方法は64bitプロセスに対しては成功しないだろう。」
Re: (スコア:0)
読み込み位置を固定アドレスに追い込むために、本当にヒープを要求して物理メモリの空きを減らさなくても、zero pageでも何でもいいからアドレス空間にマップしまくればいいような気がするんだけど。それだったら重くなったりして見た目で気づかれることなく実行できてしまうのではないかな。
Re: (スコア:0)
Re: (スコア:0)
windowsって物理メモリ+swapの合計以上の仮想アドレスは貰えもしないのだっけ？
あ、PAE有効な32bit機なら物理メモリを使い切ることなく仮想アドレス空間を埋め尽くせるんじゃ・・・
と思ったけど32bit機で4GB越えのメモリ積んだマシンなんて見たことなかった。
デメリットが表面化？ (スコア:0)
デフォルトでは ExtExport.exe ie4uinit.exe ieinstal.exe ielowutil.exe ieUnatt.exe iexplore.exe msfeedssync.exe mshta.exe PresentationHost.exe にしか設定されてないのに？
タレコミにちゃんと書いたんですが・・・ (スコア:1)
例：Win8-VC2005でコンパイルエラー（8/22日参照） — https://twitter.com/aruhan [twitter.com]
他にVC2005のリソースエディタで.rcが壊れる、VC2010でビルドログが書き込めない等のエラーが表示されるなどあります。
Visual C++のプリコンパイルドヘッダ (オフトピ: -1) (スコア:2)
Visual C++のプリコンパイルドヘッダは、ASLRと相性が悪かったみたいですね（私もVC++ 2005で同じ問題に遭遇しました）。
Visual C++ Precompiled Header Errors on Windows 7 - Visual C++ Team Blog [msdn.com]（日本語訳：本の虫: Windows 7におけるプリコンパイルドヘッダーのエラーについて [blogspot.jp]）→修正プログラム: Error message when you use the Visual C++ 2008 compiler: "fatal error C1859" [microsoft.com]
Re:Visual C++のプリコンパイルドヘッダ (スコア:0)
有用な情報ありがとうございました。助かりました。リソースを編集すると.rcが100%壊れるのですがそちらも解決法知りませんでしょうか(VC2005)
Re: (スコア:0)
EMETのチェック外したところでWindowsのASLRが無効になったりしないんだがね。
Re: (スコア:0)
ASLRを導入するとクラッキングが困難になるよ、でもトレードオフとして互換性が下がるよ。
でももうASLR回避は簡単にできるよ、トレードオフが無くなってデメリットが残るよ。
→デメリットの表面化
間違ってはいない。
Re: (スコア:0)
後者の機能をONにしないで使う分には互換性の低下とか無いはずだし。
＃ ちなみにASLRそのものはVistaから使える。Vista(SP1以降)は本当はできる子。
突然のですます調 (スコア:0)
編集者は文体の統一くらいしろと言いたいところだがそれ以前に文体がバラバラなのはコピペ切り貼りの強いサインだからまずそっちの調査からだな。
Re:突然のですます調 (スコア:1)
調査の結果、文体やタイプミスの書き込み位置をランダム化してプロファイリングを困難にする技術と判明しますた
で、他には？ (スコア:0)
様々な不具合と書きながらその実例が生ポインタの値をそのままPCHに書き出すという愚かな設計をしていたVC++しか出ていない辺り、ASLRを無効にしてのテストもせずになんでもかんでもASLRのせいにしているんだろうなと思います
Re:で、他には？ (スコア:2)
たしかに、あまり思い浮かびませんがもう1つ。CygwinもASLRでやられるアプリ（群）だと思います。Vista以降、rebaseallを使う機会が多くなりました。
forkを無理してがんばって実装しているので、DLLを特定のアドレスに読み込めないといけないようです。そのためどうしてもASLRとは相性が悪いですね。