バッファオーバーフロー

プログラミングと情報セキュリティにおいて、バッファ オーバーフローまたはバッファ オーバーランとは、プログラムがバッファに割り当てられたメモリを超えてバッファにデータを書き込み、隣接するメモリ位置を上書きする異常な状態を指します。

バッファは、データを保持するために確保されるメモリ領域であり、多くの場合、データをプログラムのあるセクションから別のセクションに移動するとき、またはプログラム間で移動するときに使用されます。バッファ オーバーフローは、不正な入力によって引き起こされることがよくあります。すべての入力が特定のサイズよりも小さいと想定し、そのサイズでバッファを作成すると、より多くのデータを生成する異常なトランザクションによって、バッファの末尾を超えて書き込まれる可能性があります。これにより隣接するデータまたは実行可能コードが上書きされると、メモリ アクセス エラー、誤った結果、クラッシュなどのプログラムの動作が不安定になる可能性があります。

バッファ オーバーフローの動作を悪用することは、よく知られたセキュリティ上の脆弱性です。多くのシステムでは、プログラムまたはシステム全体のメモリ レイアウトが明確に定義されています。バッファ オーバーフローを引き起こすように設計されたデータを送信することで、実行可能コードを保持することがわかっている領域に書き込み、悪意のあるコードに置き換えたり、プログラムの状態に関連するデータを選択的に上書きしたりして、元のプログラマが意図していなかった動作を引き起こしたりすることができます。バッファはオペレーティング システム(OS) コードに広く使用されているため、特権昇格を実行してコンピューターのリソースに無制限にアクセスする攻撃を行うことができます。1988 年の有名なMorris ワームは、これを攻撃手法の 1 つとして使用しました。

バッファ オーバーフローによく関連付けられるプログラミング言語には、 CやC++ などがありますが、これらの言語には、メモリのどの部分でもデータへのアクセスや上書きに対する保護機能が組み込まれておらず、配列(組み込みバッファ タイプ) に書き込まれたデータがその配列の境界内にあるかどうかを自動的にチェックしません。境界チェックによりバッファ オーバーフローを防ぐことができますが、追加のコードと処理時間が必要になります。最新のオペレーティング システムでは、悪質なバッファ オーバーフローに対抗するためにさまざまな手法が使用されています。具体的には、メモリのレイアウトをランダム化したり、バッファ間に意図的にスペースを残しておき、その領域に書き込むアクション (「カナリア」) を探したりします。

バッファオーバーフローは、境界チェックが不十分なために、バッファに書き込まれたデータが宛先バッファに隣接するメモリアドレスのデータ値も破壊した場合に発生します。^{[1] ：41}これは、データが宛先バッファ内に収まるかどうかを最初にチェックせずに、あるバッファから別のバッファにデータをコピーすると発生する可能性があります。

Cで表現された次の例では、プログラムにはメモリ内で隣接する 2 つの変数、8 バイト長の文字列バッファ A と 2 バイトのビッグ エンディアン整数 B があります。

char A [ 8 ] = "" ; unsigned short B = 1979 ;             
       

最初、A にはゼロバイトしか含まれず、B には数字 1979 が含まれます。

ここで、プログラムはASCIIエンコードされたNULL 終了文字列 "excessive"をA バッファーに格納しようとします。

strcpy ( A 、「過剰」); 

"excessive"は 9 文字の長さで、ヌル終端文字を含めて 10 バイトにエンコードされますが、A は 8 バイトしか取れません。文字列の長さをチェックしないため、B の値も上書きされます。

B の値は、文字列の一部から形成された数値に誤って置き換えられました。この例では、「e」の後にゼロ バイトが続くと 25856 になります。

割り当てられたメモリの終わりを超えてデータを書き込むと、オペレーティング システムによって検出され、セグメンテーション エラーが発生してプロセスが終了することがあります。

この例では、バッファ オーバーフローの発生を防ぐには、 の呼び出しstrcpyを に置き換えますstrlcpy。 は、A の最大容量 (ヌル終了文字を含む) を追加パラメータとして受け取り、この量を超えるデータが A に書き込まれないようにします。

strlcpy ( A , "過剰" , sizeof ( A ));  

使用可能な場合、ソース文字列の長さがバッファのサイズ (関数に渡される 3 番目の引数) 以上の場合、宛先バッファを NULL で終了しないライブラリstrlcpy関数が優先されます。したがって、 NULL で終了しない可能性があり、有効な C スタイルの文字列として扱うことはできません。 strncpyA

バッファ オーバーフローの脆弱性を悪用する手法は、アーキテクチャ、オペレーティング システム、およびメモリ領域によって異なります。たとえば、ヒープ(動的に割り当てられたメモリに使用される) の悪用は、コール スタックの悪用とは大きく異なります。一般に、ヒープの悪用はターゲット システムで使用されるヒープ マネージャーに依存し、スタックの悪用はアーキテクチャとコンパイラで使用される呼び出し規約に依存します。

スタックベースのバッファオーバーフローを悪用してプログラムを操作する方法はいくつかあります。

• スタック上の脆弱なバッファの近くにあるローカル変数を上書きしてプログラムの動作を変更する。
• スタック フレーム内の戻りアドレスを上書きして、攻撃者が選択したコード (通常はシェルコードと呼ばれます) を指すようにします。関数が戻ると、実行は攻撃者のシェルコードで再開されます。
• 関数ポインタ^[2]または例外ハンドラを上書きしてシェルコードを指し示し、その後シェルコードを実行します。
• 別のスタックフレームのローカル変数（またはポインタ）を上書きすることで、そのフレームを所有する関数によって後で使用されるようになります。^[3]

攻撃者は、これらのエクスプロイトのいずれかを引き起こすデータを設計し、このデータを脆弱なコードによってユーザーに提供されるバッファに配置します。スタック バッファ オーバーフローに影響を与えるために使用されるユーザー提供データのアドレスが予測できない場合、スタック バッファ オーバーフローを悪用してリモート コード実行を引き起こすことははるかに困難になります。このようなバッファ オーバーフローを悪用するために使用できる 1 つの手法は、「トランポリン」と呼ばれます。この場合、攻撃者は脆弱なスタック バッファへのポインタを見つけ、そのポインタを基準としてシェルコードの位置を計算します。次に、攻撃者は上書きを使用して、メモリ内に既に存在する命令にジャンプし、今度はポインタを基準として 2 回目のジャンプを行います。2 回目のジャンプによって、シェルコードの実行が分岐します。適切な命令は、多くの場合、大規模なコード内にあります。たとえば、 Metasploit プロジェクトは、適切なオペコードのデータベースを維持していますが、 Windowsオペレーティング システムで見つかったものだけをリストしています。^[4]

ヒープ データ領域で発生するバッファ オーバーフローはヒープ オーバーフローと呼ばれ、スタック ベースのオーバーフローとは異なる方法で悪用されます。ヒープ上のメモリは実行時にアプリケーションによって動的に割り当てられ、通常はプログラム データが含まれます。悪用は、このデータを特定の方法で破壊し、アプリケーションがリンク リスト ポインタなどの内部構造を上書きするようにすることで実行されます。標準的なヒープ オーバーフロー手法では、動的メモリ割り当てリンク ( mallocメタデータなど) を上書きし、その結果生じるポインタ交換を使用してプログラム関数ポインタを上書きします。

JPEG処理におけるMicrosoftのGDI+の脆弱性は、ヒープオーバーフローがもたらす危険性の一例です。^[5]

バッファが読み取られたり実行されたりする前に行われるバッファの操作は、悪用の試みを失敗させることにつながる可能性があります。これらの操作は悪用の脅威を軽減できますが、不可能にすることはできない可能性があります。操作には、大文字または小文字への変換、メタ文字の削除、英数字以外の文字列のフィルタリングが含まれます。ただし、英数字シェルコード、ポリモーフィックコード、自己変更コード、return-to-libc攻撃など、これらのフィルターと操作を回避する手法が存在します。同じ方法を使用して、侵入検知システムによる検出を回避することができます。コードがUnicodeに変換される場合など、^[6]場合によっては、開示者によって脆弱性の脅威がサービス拒否のみとして誤って伝えられていますが、実際には任意のコードのリモート実行が可能です。

現実世界のエクスプロイトでは、エクスプロイトが確実に動作するために克服する必要があるさまざまな課題があります。これらの要因には、アドレスのヌルバイト、シェルコードの場所の変動性、環境の違い、および動作中のさまざまな対策が含まれます。

NOP スレッドは、スタック バッファ オーバーフローを悪用する最も古く、最も広く知られている手法です。^[7]この手法は、ターゲット領域のサイズを効果的に増やすことで、バッファの正確なアドレスを見つけるという問題を解決します。これを行うには、スタックのかなり大きなセクションをno-opマシン命令で破損させます。攻撃者が提供したデータの末尾、no-op 命令の後に、攻撃者はシェルコードが配置されているバッファの先頭への相対ジャンプを実行する命令を配置します。この no-op のコレクションは「NOP スレッド」と呼ばれます。これは、戻りアドレスがバッファの no-op 領域内の任意のアドレスで上書きされた場合、実行は no-op を「スライド」して、最後のジャンプによって実際の悪意のあるコードにリダイレクトされるためです。この手法では、攻撃者は比較的小さなシェルコードではなく、スタック上のどこに NOP スレッドがあるかを推測する必要があります。^[8]

この手法は人気があるため、侵入防止システムのベンダーの多くは、使用中のシェルコードを検出するために、この no-op マシン命令のパターンを検索します。NOP スレッドには、必ずしも従来の no-op マシン命令だけが含まれているわけではありません。シェルコードが実行できなくなるほどマシン状態を破壊しない命令であれば、ハードウェア支援の no-op の代わりに使用できます。その結果、エクスプロイト作成者が、シェルコードの実行に実際には影響を与えないランダムに選択された命令で no-op スレッドを構成することが一般的な方法になっています。^[9]

この方法は攻撃が成功する可能性を大幅に高めますが、問題がないわけではありません。この手法を使用するエクスプロイトは、NOP スレッド領域内のスタック上のオフセットを推測できるかどうか、ある程度の運に頼る必要があります。^[10]推測が間違っていると、通常、ターゲット プログラムがクラッシュし、システム管理者に攻撃者のアクティビティが警告される可能性があります。もう 1 つの問題は、NOP スレッドでは、使用可能な大きさの NOP スレッドを保持するために、はるかに大きなメモリが必要になることです。これは、影響を受けるバッファーの割り当てサイズが小さすぎ、スタックの現在の深さが浅い (つまり、現在のスタック フレームの末尾からスタックの先頭までのスペースがあまりない) 場合に問題になる可能性があります。問題はありますが、NOP スレッドは、特定のプラットフォーム、環境、または状況で機能する唯一の方法であることが多く、そのため、依然として重要な手法です。

「レジスタへのジャンプ」テクニックは、NOPスレッド用の余分なスペースを必要とせず、スタックオフセットを推測する必要もなく、スタックバッファオーバーフローを確実に悪用することを可能にする。この戦略は、戻りポインタを、制御されたバッファ、つまりシェルコードを指すレジスタ内に格納された既知のポインタにプログラムがジャンプするようにする何かで上書きすることである。たとえば、レジ​​スタAにバッファの先頭へのポインタが含まれている場合、そのレジスタをオペランドとして取るジャンプまたは呼び出しを使用して、実行フローの制御を獲得することができる。^[11]

実際には、プログラムには特定のレジスタにジャンプする命令が意図的に含まれていない可能性があります。従来の解決策は、プログラム メモリ内のどこかの固定された場所で適切なオペコードの意図しないインスタンスを見つけることです。左の図Ejmp espには、i386命令のそのような意図しないインスタンスの例が含まれています。この命令のオペコードは ですFF E4。^[12]この 2 バイトのシーケンスは、call DbgPrintアドレス の命令の先頭から 1 バイトのオフセットにあります0x7C941EED。攻撃者がプログラムの戻りアドレスをこのアドレスで上書きすると、プログラムは最初に にジャンプし0x7C941EED、オペコードを命令FF E4として解釈しjmp esp、次にスタックの先頭にジャンプして攻撃者のコードを実行します。^[13]

この手法が可能な場合、脆弱性の深刻度は大幅に増大します。これは、エクスプロイトが十分に機能し、実行時に事実上成功が保証される攻撃を自動化できるためです。このため、この手法は、スタック バッファ オーバーフローの脆弱性を悪用するインターネット ワームで最も一般的に使用されています。^[14]

この方法では、Windows プラットフォームで上書きされた戻りアドレスの後にシェルコードを配置することもできます。実行可能ファイルはほとんどがアドレスに基づいており0x00400000、x86 はリトル エンディアンアーキテクチャであるため、戻りアドレスの最後のバイトは null である必要があり、これによりバッファー コピーが終了し、それ以降は何も書き込まれません。これにより、シェルコードのサイズがバッファーのサイズに制限されますが、これは制限が厳しすぎる可能性があります。DLL はハイ メモリ (上記0x01000000) に配置されているため、アドレスには null バイトが含まれません。そのため、この方法では、上書きされた戻りアドレスから null バイト (またはその他の許可されていない文字) を削除できます。このように使用されるため、この方法は「DLL トランポリン」と呼ばれることがよくあります。

バッファ オーバーフローを検出または防止するために、さまざまな手法が使用されてきましたが、それぞれにトレードオフがあります。次のセクションでは、利用可能な選択肢と実装について説明します。

アセンブリ言語、C言語、C++言語は、メモリへの直接アクセスを許可し、強く型付けされていないため、バッファオーバーフローに対して脆弱な人気プログラミング言語です。^[15] C言語には、メモリのどの部分でもデータへのアクセスや上書きに対する保護機能が組み込まれていません。より具体的には、バッファに書き込まれたデータがそのバッファの境界内にあるかどうかをチェックしません。標準のC++ライブラリには、データを安全にバッファリングする方法が多数用意されており、C++の標準テンプレートライブラリ（STL）には、プログラマがデータにアクセスする際に明示的にチェックを呼び出した場合に、オプションで境界チェックを実行できるコンテナが用意されています。たとえば、vectorのメンバー関数はat()境界チェックを実行し、境界チェックが失敗するとout_of_range 例外をスローします。^[16]ただし、境界チェックが明示的に呼び出されない場合、C++はCと同じように動作します。Cにもバッファオーバーフローを回避する手法が存在します。

COBOL、Java、Eiffel、Pythonなどの強く型付けされ、直接メモリアクセスを許可しない言語は、ほとんどの場合バッファオーバーフローを防止します。^[15] CやC++以外の多くのプログラミング言語は実行時チェックを提供し、場合によってはコンパイル時チェックも提供して警告を送ったり例外を発生させたりするのに対し、CやC++はデータを上書きし、誤った結果が得られるまで命令を実行し続け、プログラムがクラッシュする可能性があります。そのような言語の例には、Ada、Eiffel、Lisp、Modula-2、Smalltalk、OCaml、およびCから派生したCyclone、Rust、Dなどがあります。Javaおよび.NET Frameworkバイトコード環境では、すべての配列に対して境界チェックも必要です。ほぼすべてのインタープリタ言語は、明確に定義されたエラー条件を通知してバッファオーバーフローから保護します。境界チェックを行うのに十分な型情報を提供する言語では、境界チェックを有効または無効にするオプションが提供されることが多いです。静的コード分析では、多くの動的境界および型チェックを削除できますが、実装が不十分であったり、扱いにくいケースがあると、パフォーマンスが大幅に低下する可能性があります。ソフトウェア エンジニアは、使用する言語とコンパイラ設定を決定する際に、安全性とパフォーマンス コストのトレードオフを慎重に考慮する必要があります。

バッファオーバーフローの問題は、C言語やC++言語では、データ型のコンテナとしてのバッファの低レベルの表現の詳細を公開するため、よく発生します。バッファオーバーフローは、バッファ管理を実行するコードの正確性を高めることで回避できます。また、境界チェックが行われない、、などの標準ライブラリ関数の使用を避けることも長い間推奨されてきました。Morrisワームgetsは、fingerdの呼び出しを悪用しました。^[17]scanfstrcpygets

境界チェックを含むバッファ管理を一元化して自動的に実行する、適切に記述されテストされた抽象データ型ライブラリは、バッファオーバーフローの発生と影響を軽減できます。バッファオーバーフローが一般的に発生する言語の主なデータ型は、文字列と配列です。したがって、これらのデータ型のバッファオーバーフローを防止するライブラリは、必要なカバレッジの大部分を提供できます。ただし、これらの安全なライブラリを正しく使用しないと、バッファオーバーフローやその他の脆弱性が発生する可能性があります。また、当然のことながら、ライブラリ内のバグも潜在的な脆弱性になります。「安全な」ライブラリ実装には、「The Better String Library」 ^[18] 、 Vstr ^[19]、Erwin ^{[20]などがあります。OpenBSD}オペレーティングシステムのC ライブラリは、strlcpy関数とstrlcat関数を提供しますが、これらは完全な安全なライブラリ実装よりも制限されています。

2007 年 9 月、C 標準委員会によって作成された技術レポート 24731 が公開されました。^[21]このレポートでは、標準 C ライブラリの文字列関数と IO 関数をベースにした関数セットが指定され、バッファ サイズ パラメータが追加されています。ただし、これらの関数がバッファ オーバーフローを減らすのに効果的かどうかは議論の余地があります。これらの関数は、関数呼び出しごとにプログラマーの介入を必要としますが、これは、類似の古い標準ライブラリ関数をバッファ オーバーフローから安全にする介入と同等です。^[22]

バッファオーバーフロー保護は、関数が戻るときにスタックが変更されていないことを確認することで、最も一般的なバッファオーバーフローを検出するために使用されます。変更されている場合、プログラムはセグメンテーション違反で終了します。このようなシステムには、Libsafe ^[23]、StackGuard ^[24]、ProPolice ^[25] gccパッチの3つがあります。

マイクロソフトのデータ実行防止（DEP）モードの実装では、構造化例外ハンドラ（SEH）へのポインタが上書きされるのを明示的に防ぎます。^[26]

スタックを 2 つに分割することで、スタック保護を強化できます。1 つはデータ用、もう 1 つは関数の戻り用です。この分割はForth 言語に存在しますが、セキュリティに基づく設計上の決定ではありませんでした。ただし、戻りアドレス以外の機密データが上書きされる可能性があるため、これはバッファ オーバーフローの完全な解決策ではありません。

このタイプの保護は、すべての攻撃を検出できないため、完全に正確ではありません。StackGuardなどのシステムは、攻撃の動作を中心にしているため、範囲チェックシステムと比較して効率的で高速です。^[27]

バッファオーバーフローは、格納されているアドレスを含むポインタを操作することで発生します。PointGuardは、攻撃者がポインタとアドレスを確実に操作するのを防ぐためのコンパイラ拡張機能として提案されました。^[28]このアプローチは、ポインタが使用される前と後に、コンパイラがポインタを自動的にXORエンコードするコードを追加することによって機能します。理論的には、攻撃者はポインタのエンコードとデコードにどの値が使用されるかわからないため、新しい値で上書きされた場合にポインタが何を指すかを予測することはできません。PointGuardはリリースされませんでしたが、MicrosoftはWindows XP SP2とWindows Server 2003 SP1から同様のアプローチを実装しました。^[29] Microsoftは、ポインタ保護を自動機能として実装するのではなく、呼び出すことができるAPIルーチンを追加しました。これにより、パフォーマンスが向上します（常に使用されるわけではないため）が、いつ使用する必要があるかを知るという負担がプログラマーに課せられます。

XOR は線形であるため、攻撃者はアドレスの下位バイトのみを上書きすることでエンコードされたポインタを操作できる可能性があります。これにより、攻撃者がエクスプロイトを複数回試みたり、ポインタが複数の場所 (NOP スレッド内の任意の場所など) のいずれかを指すようにすることで攻撃を完了したりできれば、攻撃が成功する可能性があります。^[30] Microsoft は、部分的な上書きに対するこの弱点に対処するために、エンコード スキームにランダム ローテーションを追加しました。^[31]

実行可能領域保護は、スタックまたはヒープ上のコードの実行を防ぐバッファ オーバーフロー保護のアプローチです。攻撃者はバッファ オーバーフローを使用してプログラムのメモリに任意のコードを挿入する可能性がありますが、実行可能領域保護があれば、そのコードを実行しようとすると例外が発生します。

一部の CPU は、 NX (「No eXecute」) またはXD (「eXecute Disabled」) ビットと呼ばれる機能をサポートしています。この機能は、ソフトウェアと組み合わせて使用​​することで、データ ページ(スタックやヒープを含むページなど) を読み取りおよび書き込み可能だが実行不可としてマークできます。

一部の Unix オペレーティング システム (例: OpenBSD、macOS ) には、実行可能スペース保護 (例: W^X ) が付属しています。オプション パッケージには次のものがあります。

• パックス^[32]
• エグゼクティブシールド^[33]
• オープンウォール^[34]

Microsoft Windowsの新しいバージョンでは、データ実行防止と呼ばれる実行可能領域保護もサポートされています。^[35] 独自のアドオンには次のものがあります。

• バッファシールド^[36]
• スタックディフェンダー^[37]

実行可能スペース保護は、通常、 return-to-libc 攻撃や、攻撃者のコードの実行に依存しないその他の攻撃に対しては保護しません。ただし、以下で説明するように、 ASLR を使用する64 ビットシステムでは、実行可能スペース保護によって、このような攻撃の実行がはるかに困難になります。

アドレス空間レイアウトのランダム化 (ASLR) は、通常、実行可能ファイルのベースとライブラリ、ヒープ、スタックの位置を含む主要なデータ領域の位置をプロセスのアドレス空間内でランダムに配置するコンピューター セキュリティ機能です。

関数や変数が存在する仮想メモリアドレスをランダム化すると、バッファオーバーフローの悪用はより困難になりますが、不可能にはなりません。また、攻撃者は個々のシステムに合わせて悪用の試みを調整する必要があり、インターネットワームの試みを阻止します。^[38]同様の方法ですが、それほど効果的ではない方法として、プロセスとライブラリを仮想アドレス空間に リベースする方法があります。

ディープ パケット インスペクション (DPI) を使用すると、攻撃シグネチャとヒューリスティックを使用して、ネットワーク境界でバッファ オーバーフローを悪用する非常に基本的なリモート試行を検出できます。この手法では、既知の攻撃のシグネチャを持つパケットをブロックできます。以前は、長い一連の No-Operation 命令 (NOP スレッドと呼ばれる) が検出され、エクスプロイトのペイロードの場所がわずかに変化する状況で使用されていました。

パケット スキャンは、既知の攻撃しか防ぐことができず、NOP スレッドをエンコードする方法が多数あるため、効果的な方法ではありません。攻撃者が使用するシェルコードは、英数字、メタモーフィック、または自己変更型にすることで、ヒューリスティック パケット スキャナーや侵入検知システムによる検出を回避できます。

バッファオーバーフローをチェックし、その原因となるバグを修正することは、バッファオーバーフローの防止に役立ちます。バッファオーバーフローを発見するための一般的な自動化手法の1つは、ファジングです。^[39]エッジケーステストでも、静的解析と同様にバッファオーバーフローを発見できます。^[40]潜在的なバッファオーバーフローが検出されたら、修正する必要があります。このため、このテスト手法は開発中のソフトウェアには有効ですが、メンテナンスやサポートが終了しているレガシーソフトウェアにはあまり有効ではありません。

バッファオーバーフローは、1972年にコンピュータセキュリティ技術計画調査で「この機能を実行するコードは送信元アドレスと送信先アドレスを適切にチェックしないため、モニターの一部をユーザーがオーバーレイできるようになります。これを利用してモニターにコードを挿入し、ユーザーがマシンの制御を奪取できるようになります。」と説明された時点ですでに認識され、部分的に公開されていました。^[41]今日では、モニターはカーネルと呼ばれています。

バッファオーバーフローの悪意ある悪用が最初に記録されたのは 1988 年のことでした。これは、インターネット上で増殖するためにMorris ワームが使用したいくつかの悪用のうちの 1 つでした。悪用されたプログラムは、fingerと呼ばれるUnixのサービスでした。^[42]その後、1995 年に Thomas Lopatic がバッファオーバーフローを独自に再発見し、Bugtraqセキュリティ メーリング リストで発見事項を発表しました。^[43] 1 年後の 1996 年に、Elias Levy (別名 Aleph One) がPhrack誌に「Smashing the Stack for Fun and Profit」という論文を発表しました。^[44]これは、スタックベースのバッファオーバーフロー脆弱性の悪用方法を段階的に紹介するものです。

それ以来、少なくとも2つの主要なインターネットワームがバッファオーバーフローを悪用して多数のシステムを侵害してきました。2001年には、Code RedワームがMicrosoftのインターネットインフォメーションサービス（IIS）5.0のバッファオーバーフローを悪用し^[45]、2003年にはSQL SlammerワームがMicrosoft SQL Server 2000を実行しているマシンを侵害しました。^[46]

2003年、ライセンスを受けたXboxゲームに存在するバッファオーバーフローが悪用され、自作ゲームを含むライセンスのないソフトウェアを、 modchipと呼ばれるハードウェアの変更を必要とせずにコンソールで実行できるようになりました。^[47] PS2 Independence Exploitもバッファオーバーフローを使用してPlayStation 2で同じことを実現しました。Twilight hackは、ゼルダの伝説 トワイライトプリンセスのバッファオーバーフローを使用して、Wiiで同じことを達成しました。

• 「FTP サーバーのリモート バッファ オーバーフロー脆弱性の発見と悪用」by Raykoid666
• 「楽しみと利益のためにスタックを壊す」Aleph One著
• Gerg, Isaac (2005-05-02). 「バッファオーバーフローエクスプロイトの概要と例」(PDF) . IAnewsletter . 7 (4). Information Assurance Technology Analysis Center : 16–21. 2006-09-27 にオリジナル(PDF)からアーカイブ。2019-03-17に取得。
• CERT セキュアコーディング標準
• CERT セキュアコーディングイニシアチブ
• C および C++ でのセキュアコーディング
• SANS: バッファオーバーフロー攻撃の内幕
• 「隣接メモリオーバーフローの進歩」Nomenumbra
• バッファオーバーフロー防止の実装と弱点の比較
• バッファオーバーフローに関するその他のセキュリティホワイトペーパー
• 第 12 章:ソケット、シェルコード、移植、コーディングからのエクスプロイト III の作成: セキュリティ専門家向けのエクスプロイトのリバース エンジニアリングとツール コーディング、James C. Foster 著 ( ISBN 1-59749-005-9 )。Metasploit を使用してバッファ オーバーフロー エクスプロイトをゼロから開発する方法について詳しく説明します。 
• コンピュータ セキュリティ技術計画調査、James P. Anderson、ESD-TR-73-51、ESD/AFSC、Hanscom AFB、Bedford、MA 01731 (1972 年 10 月) [NTIS AD-758 206]
• Nevermore による「バッファ オーバーフロー: エクスプロイトの分析」
• GCC と GLibc によるセキュアプログラミング(2008 年)、 Wayback Machineで2008 年 11 月 21 日にアーカイブ、Marcel Holtmann 著
• 「バッファオーバーフローによる悪用の危険 – パート 0 – テオリアの危険」 (2018)、Helvio Junior (M4v3r1ck) 著