問題タブ [aslr]

長いデバッグ作業の後、アプリケーションがアドレス 0x5b81730 に間違った値を書き込んでいる可能性があることがわかりました。コードのどの部分がこれを行っているかを知りたいです。

以前、Windows XP を使用していたときは、これは非常に簡単でした。デバッガー (MS Visual Studio 2005) でアプリケーションを再起動し、そのアドレスにデータ ブレークポイントを設定すると、デバッガーは問題のあるコードを指摘します。

今、Windows 7 に切り替えた後、これは不可能に思えます (少なくとも非常に困難です)。アプリケーションを実行すると、ヒープ内の同じオブジェクトのアドレスが毎回わずかに異なることがわかります (たとえば、ある実行では 0x53b71b4 ですが、別の実行では 0x55471b4 になります)。

Windows 7 にはASLRがあると聞いたことがあります。これが、アドレスにこれらの変更が見られる理由かもしれません。

では、デバッグ手法を引き続き使用するにはどうすればよいでしょうか?

ASLR をオフにする必要がありますか? （可能だと思いますが、方法がわかりませんでした）

それとも、私の問題は ASLR ではなく、別の何かによって引き起こされているのでしょうか?

それとも、データ ブレークポイントを使用する便利さを忘れて、他の手法を使用する必要がありますか?

これは、 「urandom に似ていますが、エントロピー プールの枯渇を最小限に抑えることを目的としています」random.cというカーネル ソースで言及されています。get_random_intしかし、どこで (そしてどのように)get_random_intエントロピー プールと相互作用するのでしょうか?

さて、urandom実際に を呼び出しますextract_entropy_userが、 に似たものは見当たりませんget_random_int。get_random_int独自のエントロピー ソースを使用しているようです(キーボード、マウス、およびディスクのアクティビティとは関係ありません)。

システムで一般的に利用可能なエントロピーの状態を気にしない（または更新しない）のですか？

エントロピー プールはどのようにget_random_int枯渇しますか? これはどこで更新されますか? プログラムを実行すると、entropy_avail で cat を実行するだけで、エントロピー プールがどのように枯渇するかを確認できるため、何かが足りないか、ソースを間違って読んでいることがわかります。

http://xorl.wordpress.com/2011/01/16/linux-kernel-aslr-implementation/を調べましたが、これがどのように機能するかについては言及されていないようです。

そのため、起動時に特定のアプリにフックして、ユーザーがアプリのゲーム内 mod を使用できるようにするジェイルブレイクの微調整に取り組んでいますが、これを機能させる唯一の方法は、ASLR が無効になっているアプリを使用することです。法律により ASLR を無効にしたバージョンのアプリをリリースできないため、ASLR を無効にせずにアプリのメモリ ロケーションを計算する方法を確認したいと考えています。私はそれが以前に行われたのを見たことがありますが、他の誰かがそれを再現する方法を知っているかどうか疑問に思っています.

バッファ サイズを増やすと、ASLR ブルート フォースが成功する可能性がどのように増加しますか?

これは、私が最近行ったプロジェクトに関連しています。バッファ/文字配列 (元のサイズは 517) を持ったエクスプロイト_1.c プログラムがありました。バッファーは memset で NOP に設定されました。次に、シェルコードとリターン アドレスをバッファーに配置し、それを badfile というファイルに書き込みました。プログラムは戻りアドレスである 1 つの引数を取ります。私たちは、bof と呼ばれる関数で、badfile の内容をサイズ 12 のバッファーにコピーする stack.c プログラムを用意しました。

NOPスレッドの最後にジャンプを配置し、シェルコードにリダイレクトさせる方法があることを読んだことがあります。ただし、シェルコードは 24 バイトで、リターン アドレスの前に最大で 16 バイトしかありませんでした。だから私がしたことは、シェルコードをバッファの最後に置くことです。

与えられた 3 番目のタスクは、バッファ サイズ 1000、10000、および 100000 でエクスプロイト プログラム (もちろんバッファ サイズ用に変更されています) が成功する平均確率が高くなるようにリターン アドレスを選択することです。 ASLRブルートフォースが何回試行されたかをカウントします。

だから私が考えていたのは、メモリが増えると明らかにNOPスレッドが長くなるということです。しかし、それ以上の何かがあるはずです。

私が選んだアドレスは: 0xbf87f030 0xbf82e3d0 0xbfe0fb60

Address Space Layout Randomization について読んだばかりで、非常に単純なスクリプトを試してブルート フォースを試みました。これは、いくつかのことをテストするために使用したプログラムです。

このコマンドでコンパイルしました：

ASLR が有効になっていることを確認しました。

次に、この簡単なスクリプトを思いつきました。

フォーマットは

このスクリプトを数秒間実行すると、希望どおりにエラー コード 1 で終了します。execv("/bin/sh", ...) を呼び出す他のシェルコードも試しましたが、同様に成功しました。

リターン アドレスの後でさえ、これほど長い NOP スライドを作成できるのは奇妙に思います。ASLR の方が効果的だと思っていましたが、何か見逃していましたか? アドレス空間が小さすぎるからですか？

編集:私はいくつかの追加の調査を行いましたが、ここに私が見つけたものがあります:

• 私は友人に-m32 -z execstack、彼の 64b コンピューターでこのコードを実行するように依頼しました。リターン アドレスを少し変更した後、彼は同じ結果を得ました。

• を使用しませんでしたが-z execstack、シェルコードを実行できました。さまざまなシェルコードを使用して、すべてが本来の機能を実行することでそれを確認しました（よく知られているシナリオchown root ./vulでさえ、実行され、最終的に生成されたシェルで「ルート」を返すシェルコード）chmod +s ./vul。実行可能なスタック フラグ ビットが設定されていないことがわかったので、これは非常に奇妙です。誰かが理由を知っていますか？setreuid(0, 0)execv("/bin/sh", ...)whoamiexecstack -q ./vul

次の C++ クラスを検討してください。

私が使用するコンパイラは、メモリ内のメンバーの順序がクラス定義で使用した順序と同じになるように、このクラスの表現を作成します。私は最近、この事実を悪用してメンバーを初期化するプログラムに遭遇しました。レイアウトはコンパイラに依存するため、これが非常に悪い考えであることはわかっていますが、コードを書いていないので、これまでのところうまくいきました。

ASLR現代のオペレーティングシステムの機能がこれを台無しにするのではないかと思っていました。オブジェクトが で動的にインスタンス化されている場合、これは当てはまらないと確信していますheap。しかし、他の場合はどうでしょうか。

次の脆弱なコード/プログラムを検討してください。

NX と ASLR が有効になっている Linux を実行している IA-32 (x86、32 ビット) では、基本的に次の手順を含む GOT 上書き手法を使用してこれを悪用します。

1. RIP までのオーバーフロー バッファ
2. のアドレスで RIP を上書きします。strcpy@plt
3. .textからのクリーンなガジェットを使用してくださいpop edi ; pop ebp ; ret。strcpy
4. 次の引数を書き込みますstrcpy: &bss-address を宛先として、1 バイトを/bin/sh使用して.text
5. /bin/shが完全に書き込まれるまで、手順 2 ～ 4 を繰り返します。&bss
6. strcpywithの GOT エントリを上書きしsystemます (オフセットを使用するため、Libc の使用バージョンに関する知識が必要です - ここでは無視しましょう)
7. スタックに書き込みstrcpy@plt、続いて 4 バイトのチャンク、最後にどのアドレス&bssを指すか/bin/sh
8. 利益

同じ緩和策を有効にして x86-64 でこれを悪用したいと考えています。しかしこれは想像以上に難しい。基本的に次の理由によります。

1. x86-64 レジスタ ベースの呼び出し規約: 関数の引数は、スタックではなくレジスタを使用して渡されます。したがって、引数をスタックから適切なレジスタに転送するには、いくつかの追加の ROP ガジェットが必要です。これは小さな問題ですが、次の問題の影響も受けます。

2. 64 ビットの戻りアドレス: x86-64 の RIP は、.text32 ビット長でさえありません。したがって、関数呼び出しを連鎖させるには、スタックに NULL バイトを書き込む必要があります。基本的には、連鎖呼び出しを使用してstrcpy、NULL 終了文字strcpy が常に書き込むことを利用して、必要なだけ NULL バイトを書き込むことができます。strcpyただし、RIP の最下位バイトを上書きするだけで、1 回だけ呼び出すことができます。

   /li>

これらは、NX と ASLR が有効になっている x86-64 でプログラムを悪用したときに発生した主な問題です。これらの問題を解決するテクニックはありますか? それとも、x86-64 は、実際に機能するシェルを開くエクスプロイトを防げるのでしょうか?

NX ビットと ASLR の両方で保護されている x86-64 上の Windows で攻撃者が命令ポインターを制御できるようになった場合、NX ビット保護はどのようにオフになりますか? この機能を無効にするシステム コールは、単純に ASLRed 以外のアドレスにあり、直接呼び出すことができると思いますか?

ヒープ スプレーは、最新の Windows マシンを悪用するために頻繁に使用されるようです (Javascript 実装のバグなど)。Windowsでこれがどのように行われるかを明確に示している紙はありますか?