問題タブ [stack-smash]

今日、どうやら私のスタックが破壊され、G++ リターンポイント カナリアがオーバーライドされたという楽しいバグがありました (これが使用されている保護だと思います)。

私の問題のあるクラスはこれでした：

つまり、クライアント変数は初期化子リストで初期化されましたが、エンドポイントでは初期化されませんでした (1 つのエンドポイントにしか送信しないため、ClientSendContext では使用されませんが、問題はありません)。スマッシュ スタックは、テスト (またはそのようなもの) を実行する 3 回ごとに 1 回発生しましたが、これは奇妙です。

ただし、エンドポイント変数を削除するとすぐに、正常に動作します! どうすればいいの？それはまったく使用されませんでした.g ++はそれについて私に警告しませんでした.Valgrindも静かでした.

(担当者が高い人は、私の質問を編集して、スタックスマッシュなどをタグとして追加してもらえますか?)

よし、ペーストビンに投稿されたより多くのコードを含む更新：

http://pastebin.com/xiWx8xjV

それが呼び出されたすべてのメソッドである必要があります。最も内側の send メソッドは、テンプレート化されたクラスの一部です。UdpServer がそれを使用する場合、同じ send メソッドが正常に機能します。

編集:コードはここに直接配置されます:

そしてエラーメッセージ：

生成されたコードのスタックスマッシングエラーを追跡しようとしています。問題は、スタックスマッシングエラーが100％決定論的ではなく、1台のマシンでのみ発生し、他のマシンでは発生しないことです。行動の違いにはどのような理由が考えられますか？

スタックプロテクターフラグを使用してgccを実行しています。

クラス割り当てのためにプログラムに対してバッファオーバーフロー攻撃を実行しようとしています。攻撃プログラムと脆弱なプログラムの両方が私によって書かれています。

脆弱なコードはscanf、stdinからデータを読み取るために使用します。

./vulnerable < malicious_payload_file.txt正常に動作します。 more malicious_payload | ./vulnerableまたecho JUNK_JUNK_JUNK_JUNK | ./vulnerable、期待どおりに機能します。

ただし、攻撃プログラムを使用して、プログラムがクラッシュするまで、徐々に長いペイロードを供給し続けたいと思います。したがって、ジャンクのより大きなペイロードを動的に生成する必要があります。私はsystem ("./vulnerable");、異常終了を繰り返し呼び出してテストするために使用しています。

そのようなペイロードを指定するにはどうすればよいですか？

./vulnerable < malicious_payload_binary悪意のあるペイロードをファイルに入れる必要はないが、コマンドラインで指定できるような方法で実行する方法はありますか？

Core i7 720QM プロセッサを使用しており、仮想マシンとして Slackware 13.37 (32 ビット) を実行しています。クラスの課題として、脆弱なプログラムを作成し、スタックを破壊する必要があります。ただし、ほとんどのコンピューターでは、何らかの種類のスタック実行防止 (NX ビット?) があるため、これは機能しません。CPU がスタック上のデータを実行しようとする試みを検出すると、「セグメンテーション フォールト」が生成されます。

これを無視するために、または同様の方法でカーネルに通知する方法はありsysctlますか?

replyは S|[2 3 4 5 6 7 8 9]|[2 3 4 5 6 7 8 9]

スタックスマッシュを引き起こします。sscanfは通常安全ではないことは知っていますが、文字列を正常に入力すると、なぜここで失敗するのか疑問に思います。

出力は次のとおりです。

*スタックスマッシングが検出されました*：./ testClientが終了しました=======バックトレース：========= /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x1f5df0] /lib/i386-linux-gnu/libc.so.6(+0xe5d9a)[0x1f5d9a] ./testClient[0x804b336]/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37]。 / testClient [0x804add1]

=======メモリマップ：======== 00110000-0026a000 r-xp 00000000 08:01 523281 /lib/i386-linux-gnu/libc-2.13.so 0026a000-0026b000 --- p 0015a000 08:01 523281 /lib/i386-linux-gnu/libc-2.13.so 0026b000-0026d000 r--p 0015a000 08:01 523281
/lib/i386-linux-gnu/libc-2.13.so 0026d000-0026e000 rw- p 0015c000 08:01 523281 /lib/i386-linux-gnu/libc-2.13.so 0026e000-00271000 rw-p 00000000 00:00 0 00271000-00286000 r-xp 00000000 08:01 523299
/ lib / i386-linux-gnu /libpthread-2.13.so 00286000-00287000 r--p 00015000 08:01 523299 /lib/i386-linux-gnu/libpthread-2.13.so 00287000-00288000 rw-p 00016000 08:01 523299
/ lib / i386-linux- gnu / libpthread-2.13.so 00288000-0028a000 rw-p 00000000 00:00 0 003e8000-00404000 r-xp 00000000 08:01 523304
/lib/i386-linux-gnu/ld-2.13.so 00404000-00405000 r--p 0001b000 08:01 523304 /lib/i386-linux-gnu/ld-2.13.so 00405000-00406000 rw-p 0001c000 08:01 523304 /lib/i386-linux-gnu/ld-2.13.so 004c9000-004d0000 r-xp 00000000 08:01 523283
/lib/i386-linux-gnu/librt-2.13.so 004d0000-004d1000 r--p 00006000 08： 01 523283 /lib/i386-linux-gnu/librt-2.13.so 004d1000-004d2000 rw-p 00007000 08:01 523283 /lib/i386-linux-gnu/librt-2.13.so 0053f000-00540000 r-xp 00000000 00： 00 0 [vdso] 007c9000-007ed000 r-xp 00000000 08:01 523303
/lib/i386-linux-gnu/libm-2.13.so 007ed000-007ee000 r--p 00023000 08:01 523303 / lib / i386-linux-gnu /libm-2.13.so 007ee000-007ef000 rw-p 00024000 08:01 523303 /lib/i386-linux-gnu/libm-2.13.so 00cee000-00dcd000 r-xp 00000000 08:01 1051412
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.14 00dcd000-00dd1000 r--p 000de000 08:01 1051412 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14 00dd1000- 00dd2000 rw-p 000e2000 08:01 1051412
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.14 00dd2000-00dd9000 rw-p 00000000 00:00 0 00e51000-00e53000 r-xp 00000000 08:01 1070941
/ usr / lib / libboost_system.so.1.46.1 00e53000-00e54000 r--p 00002000 08:01 1070941 /usr/lib/libboost_system.so.1.46.1 00e54000-00e55000 rw-p 00003000 08:01 1070941 / usr / lib /libboost_system.so.1.46.1 00e9c000-00eb6000 r-xp 00000000 08:01 523308
/lib/i386-linux-gnu/libgcc_s.so.1 00eb6000-00eb7000 r--p 00019000 08:01 523308 /lib/i386-linux-gnu/libgcc_s.so.1 00eb7000-00eb8000 rw-p 0001a000 08:01 523308 /lib/i386-linux-gnu/libgcc_s.so.1 08048000-08067000 r-xp 00000000 08:01 1591111
/ home / alex / pj / cpp / testClient / bin / Debug / testClient 08067000-08068000 r--p 0001e000 08:01 1591111
/ home / alex / pj / cpp / testClient / bin / Debug / testClient 08068000-08069000 rw-p 0001f000 08:01 1591111
/ home / alex / pj / cpp / testClient / bin / Debug / testClient 09050000-09071000 rw-p 00000000 00:000[ヒープ]b78d9000-b78dd000rw-p 00000000 00:00 0 b78ef000-b78f2000 rw-p 00000000 00:00 0 bfba9000-bfbca000 rw-p 00000000 00:000[スタック]

私はクレイグリストの結果のリストをフィルタリングするプログラムに取り組んでいます。比較的安い賃貸部屋を探したいです。完成したプログラムは、600ドルを超える価格の行を削除し、新しいファイルを作成しますが、今のところ、$文字を含むすべての行を削除し、端末に印刷しています。

このプログラムは、独自のソースで実行すると正常に動作しますが、Firefoxから保存されたクレイグリストの結果のhtmlページで実行すると、閉じ括弧まで印刷され、スタックスマッシング検出警告とバックトレースがスローされます。私はK＆RからCを学んでいるので、このコードが時代遅れに見える場合はそれが理由です。

上記のCプログラムを、スタック保護（gcc -fno-stack-protector -o out test.c）を使用せずにrootとしてコンパイルし、通常のユーザーとして利用しました。ルートシェルを取得できませんでした。

これは、「smashthestack」から利用したものと同じコードです。

COM オブジェクト ( ) からメソッドを呼び出すコードが少しありますIDirect3D9が、すべての呼び出しでランタイム チェック エラー #0 が発生します。失敗は、呼び出し全体で ESP が適切に保持されていないために発生するため、何らかの種類のスタックの問題 (COM メソッドがすべてであるため__stdcall) です。珍しい部分は、メソッドの署名と状況の単純さです。

コードは、DirectX SDK (2010 年 6 月) ヘッダーとライブラリを使用して、MSVC 10 (VS 2010 SP1) で 32 ビット モードのみでビルドされます。ヘッダーが破損していないことを確認するために SDK を再インストールしましたが、運が悪かったのです。

VSのデバッガーとWinDBGの両方を接続してコードを実行し、再起動/ドライバーの更新後に複数回実行しました。問題は毎回発生し、同じです。gflags でヒープ検証 (および他のほとんどのオプション) を有効にしても、それ以上の情報は提供されないようです。どちらも、ポップアップと同じエラー、またはその直後に発生した segfault を報告するだけです。

呼び出しがなければ (代わりに定数値を返す)、プログラムは期待どおりに実行されます。ここで何がうまくいかないのかについてのアイデアがありません。

問題の関数はIDirect3D9::GetAdapterModeCount、D3D8-to-9 ラッパー (古いゲームのグラフィックス アップグレード プロジェクトの一部) から呼び出されます。より一般的な情報については、完全なファイルがここにあります。

次の形式の呼び出しをすべて試しました。

これらすべてがチェックの失敗を引き起こします。m_Objectは有効なIDirect3D9であり、以前はさまざまな他の呼び出しに使用されていました。具体的には次のとおりです。

シーケンスはデバッグ トレース コードによってログに記録され、正しいように見え、期待値 (3 つのモニターなど) を返します。私の側の同じオブジェクト（の単一インスタンスCVoodoo3D8）による最初の3つの呼び出しは、スタック警告なしですべて成功します。4番目はそうではありません。

呼び出しを並べ替えてGetAdapterModeCount、同じオブジェクト内の他のオブジェクトの直前に呼び出されるようにすると、同じ実行時チェックの失敗が表示されます。テストから、これはスタックを破壊する直前の呼び出しを除外するようです。これら 4 つの関数を呼び出す 4 つのメソッドはすべて異なる場所で発生し、GetAdapterModeCountこのファイル内のどこからでも呼び出すと問題が発生します。

これは私たちを珍しい部分に導きます。別のクラス ( CVoodoo3D9) も同様のパラメーターを使用して同じ一連のIDirect3D9メソッドを呼び出しますが、失敗しません (D3D9 の同等のラッパー クラスです)。オブジェクトは同時に使用されません (必要なレンダリング プロセスに応じてコードが選択されます) が、両方とも毎回同じ動作をします。他のクラスのコードは別のファイルに保持されているため、プリプロセッサの問題が疑われました (これについては後ほど説明します)。

その後、何の情報も得られなかったので、コードとパラメーターの呼び出し規約を調べました。繰り返しますが、何も明らかになりませんでした。/w4 /wXコードベースは、ほとんどの関数で SAL を使用し、すべての PREfast ルールを有効にして (そして合格)、しばらくの間コンパイルされています。

特に、このクラス内で呼び出された場合、メソッドへの呼び出しがコードからのものであるか、オブジェクトを使用する別のプログラムからのものであるかにかかわらず、呼び出しは失敗します。呼び出された場所に関係なく失敗しますが、このファイル内でのみ失敗します。

完全な方法は次のとおりです。

その時点までの実行が許可されている場合、呼び出しの直後GetAdapterModeCountとメソッドが戻ると、チェックの失敗が発生します。

preprocess-to-file オプションで指定されたプリプロセッサの出力には、( からのd3d9.h) メソッド宣言が次のように正しく含まれています。

私のメソッドの宣言は本質的に同じです:

私の方法はほとんど拡張されず、次のようになります。

プリプロセッサの出力は、宣言と定義の両方のメソッドで正しいようです。

障害が発生するまでのアセンブリ リストは次のとおりです。

明確にするために、エラーは6423861F(への呼び出し_RTC_CheckEsp) で発生し、呼び出しまたは準備がスタックを壊したことを示唆しています。同じ通話が他の場所でも機能するため、通話を壊すものではないという前提で作業しています。

私の素人の目には、唯一の異常な部分は のペアですmov register, dword ptr [register+8]。これは 32 ビット システムであるため、+8インクリメントしすぎている可能性があるかどうか、またはそうである場合にビルドにどのように組み込まれるかはわかりません。

私のメソッドが戻った直後に、ESP を破壊する呼び出しが原因で、プログラムが segfault します。値を呼び出さずGetAdapterModeCountに単に値を返せば、プログラムは期待どおりに実行されます。

さらに、リリース ビルド (RTC なし) は、同様の時点でスタックを使用して segfaults を実行します。

アドレスの意味はわかりませんが。私が知る限り、デバッグ ビルドで segfault が発生するのと同じ場所ではありません。これらは、メソッドが返された後のプログラム内にあります。これは、D3D8 からデータを取得するメソッドの 1 つの間にあるようです。編集:セグメンテーション違反は、現在デバッグ中の後の呼び出しで発生します。

この時点で、私は何がうまくいかないのか、どのようにうまくいかないのか完全に途方に暮れており、チェックするものはありません。

問題の原因となっているコード行は

以下のように、最適化オプションを 1 つだけ指定して同じコードを記述した場合、エラーは返されません。

この問題の解決を手伝ってください。どんな助けでも大歓迎です。ありがとうございました。

機能全体はこちら..

}

エラーは...

複雑な C++ コードがあります。これは、 FastCGI C++ クラス ライブラリを使用した FastCGI プログラムです。

非常に長いURLを要求すると、次のようになります。

実際のアプリケーションでは、私はそれほど長い URL を使用したことがないので問題にはなりませんが、これは、誰かが私のサーバーを終了できることを意味します... 私はそれが好きではありません。

この問題が発生する場所を見つけるツールはありますか? どうやって使うの？

編集：解決済み

私はこれをしていました：

テスト200には高すぎたようです。len実際には で失敗し194ます。

だから代わりに私はこれをしました：

さて、大丈夫です。