2

Code Complete 2を読んでいて、エラー処理で次のステートメントに出くわしました。

エラー処理ルーチン/オブジェクトを呼び出します。もう 1 つの方法は、エラー処理をグローバル エラー処理ルーチンまたはエラー処理オブジェクトに集中化することです。このアプローチの利点は、エラー処理の責任を一元化できるため、デバッグが容易になることです。トレードオフは、プログラム全体がこの中心的な機能を認識し、それに結合されることです。システムのコードを別のシステムで再利用したい場合は、再利用するコードと一緒にエラー処理機構をドラッグする必要があります。

そして後でそれは言います:

このアプローチには、セキュリティ上の重要な意味があります。コードでバッファー オーバーランが発生した場合、攻撃者がハンドラー ルーチンまたはオブジェクトのアドレスを侵害した可能性があります。したがって、アプリケーションの実行中にバッファ オーバーランが発生すると、この方法を使用しても安全ではなくなります。

しかし、上記の文はよく理解できませんでした。バッファ オーバーランはどのようにアドレス侵害を引き起こす可能性がありますか?

4

1 に答える 1

2

これは、エラー処理関数のアドレスが、プラットフォームに応じて 32 ビットまたは 64 ビットの整数のように、アプリケーションからアクセス可能なメモリ領域に格納されるためです。これは通常、スタックの一番下のどこかにありますが、グローバル エラー ハンドラの場合は、スレッドがそこに到達する方法を知っている限り、別の場所にある可能性があります。

バッファ オーバーランのシナリオでは、このメモリが別の関数のアドレスで上書きされると、アプリケーションでエラーが発生したときに、予想されるエラー処理関数ではなく、新しい関数が呼び出されます。

詳細はすべて、プログラムで使用されるフレームワークまたはオペレーティング システムに依存することに注意してください。このチュートリアルには、Windows の良い例があります。

http://www.primalsecurity.net/0x3-exploit-tutorial-buffer-overflow-seh-bypass/

とはいえ、バッファー オーバーランは、アドレスを置き換えずにエラー ハンドラーを危険にさらす可能性があります。古典的な例は、グローバル エラー ハンドラーを使用してドキュメントをファイルに保存するテキスト エディターの例です。プログラムの知識を持つ攻撃者は、バッファ オーバーフローを使用して、ファイル ストリーム ハンドルを制御する別のリソース (ネットワーク ソケットなど) に置き換え、出力を傍受する可能性があります。

于 2014-09-16T11:55:54.510 に答える