4

バッファオーバーフロー攻撃がどのように機能するかを調べ始め、Visual C2010を使用してWindows7での攻撃をシミュレートしようとしました。バッファオーバーフロー攻撃は非常に工夫されており、リターンアドレスを「バッファ」ローカル変数のアドレスに上書きするだけです。バッファはシェルコードの文字列を保持します。

Visual Studio 2010デバッグでプログラムを実行するかどうかに関係なく、プログラムはシェルコードにジャンプして実行を開始しますが、アクセス違反エラーが発生し、プログラムはシェルコードの実行を続行しません。

なぜこのエラーが発生するのですか？これは、Windowsのバッファオーバーフローに対するある種の保護ですか？

プログラムにバッファ内のシェルコードを実行させるにはどうすればよいですか？

編集：

ハンス（答え）は正しいです。これについては、Windows Internals 5thのセキュリティの章で説明されています。エラーの原因は、MicrosoftによるExecutableSpaceProtectionの実装です。

この質問が誰かを助けたなら、どんな賛成票もいただければ幸いです。

void execute_my_shellcode()
{
    char buffer[24];
    memcpy(buffer, "\x6A\x21\xFF\x15\x40\x62\x40\x00\x83\xC4\x04\x6A\x0A\xFF\x15\x40\x62\x40\x00\x83\xC4\x04\xC3", 24); 
    printf("current return address: %p\n", *(int*)((char*)&buffer + 24 + 4));   
    *(int*)((char*)&buffer + 24 + 4) = (int)&buffer; 
    printf("return address is now : %p\n\n", (int*)*(int*)((char*)&buffer + 24 + 4) );
}
4

4 に答える 4

7

これは10年前に機能した可能性があります。これらの明らかなセキュリティホールにはパッチが適用されており、プロセッサが現在サポートしている非実行ビットは対策の1つです。

于 2011-04-10T19:45:58.737 に答える
1

まず、シェルコードにはnullが含まれています。シェルコードに戻って、シェルコードが文字列として扱われないように、ヌルオペコード（0x00）を生成しない命令を見つけます。

第二に、アクセス違反は必ずしもそれが何らかのタイプの保護スキームの原因であることを意味するわけではありません。差出人住所またはシェルコードがEIPレジスタをメモリ内で実行できない場所にジャンプさせようとしている可能性があります（気まぐれです）。

あなたはもっと期限切れにする必要があります。コンパイラとコンピュータはそれぞれ異なります。ほぼすべてを回避する方法があります。一般的なトピックについてさらに調査することをお勧めしますが、最初に提案するのは、シェルコードの前にあるバッファー内のNOPスレッドを指す繰り返しリターンアドレスを作成して、シェルコードがより効率的に実行され、より多くの可能性が高くなるようにすることです。正確。

あなたが述べたように、実行可能スペース保護は正しいですが、上記の私の答えは非公式であり、ほとんどの場合必要です。ハッピーハッキング:)

于 2012-05-07T17:06:59.573 に答える
1

スタックフレームの各開始と終了のガードページなど、これを不可能にする可能性のあるバッファオーバーフロー攻撃に対する他の保護があります。アドレス空間配置のランダム化などがあります。 これに関する記事があります。

事実は、シェルコードにnullbytesまたは他のタイプの無効なcharが含まれている可能性があり、変換されたときに命令または有効なアドレスに変換されないことです...それはあなたが理解するためのものです。

私はこの後者のアドバイスを乱用するつもりはないことに注意してください。あなたは、このアドバイスを合法かつ正しく使用する責任があります。

于 2011-04-10T21:16:24.290 に答える
0

プログラムはどこで壊れていますか？OllyDbgを使用してアセンブリ手順を実行し、少なくともバッファーの実行を開始しているか、それ以前に失敗していないかを確認しましたか？バッファ内の最初の命令も実行していない場合は、スタックページ（または文字列リテラルとして指定しているため、この場合はデータセクション）が実行不可としてマークされている可能性があり、別の手法を使用する必要があります。テスト/学習の目的でスタックページ（この場合はデータセクション）を実行可能にするようにWindowsに指示する方法があるかもしれません（ELFバイナリには実行可能スタックフラグがあり、Linuxにはexecstackフラグを編集するユーティリティがあります）。

バッファからのいくつかの命令の後で壊れている場合は、バッファ内の命令が（間接的に）絶対アドレスを呼び出そうとしているため（0xff 0x15 0x40 0x62 0x40 x00=> call dword ptr ds:[406240]）、W7ではアドレス空間配置のランダム化（ASLR）が有効になっている可能性があります（I ' m VS2010リンカーがデフォルトでPEヘッダーのIMAGE_DLLCHARACTERISTICS_DYNAMIC_BASEビットを設定するかどうかわからない）。

編集

質問に追加した追加情報に基づくと、私の最初の段落で述べた実行不可能なスタックの問題が原因であるように思われます。ただし、それを回避したとしても、ASLRが有効になっている場合、0x00406240で何が起こるかわからないため、2番目の問題が依然として問題である可能性があります。

于 2011-04-10T21:31:15.133 に答える