バッファオーバーフロー

ソフトウェア バッファ オーバーフローの視覚化。データは A に書き込まれますが、大きすぎて A に収まらないため、B にオーバーフローします。

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

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

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

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

技術的な説明

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

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

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

初期状態では、A には 0 バイトのみが含まれ、B には数値 1979 が含まれています。

変数名 B
価値 [ヌル文字列] 1979年
16 進値 00 00 00 00 00 00 00 00 07 BB

ここで、プログラムはASCIIエンコードを使用してヌル終了文字列を A バッファに保存しようとします。 "excessive"

strcpy ( A , "過剰" ); 

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

変数名 B
価値 'e' 'x' 'c' 'e' 's' 's' 'i' 'v' 25856
16進数 65 78 63 65 73 73 69 76 65 00

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

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

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

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

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

搾取

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

スタックベースの悪用

技術的な傾向のあるユーザーは、スタックベースのバッファ オーバーフローを悪用して、次のいずれかの方法でプログラムを有利に操作する可能性があります。

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

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

ヒープベースの悪用

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

JPEG の処理におけるMicrosoftGDI+ の脆弱性は、ヒープ オーバーフローが引き起こす危険性の一例です。[5]

搾取に対する障壁

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

悪用の実際性

実際のエクスプロイトでは、エクスプロイトが確実に動作するために克服する必要のあるさまざまな課題があります。これらの要因には、アドレス内のヌルバイト、シェルコードの場所のばらつき、環境間の違い、運用時のさまざまな対策などが含まれます。

NOPスレッドテクニック

スタック上の NOP スレッド ペイロードの図。

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

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

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

レジスタに格納されたアドレスへのジャンプ手法

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

ルーチンを呼び出すための ntdll.dll からの命令には、DbgPrint()i386マシン オペコードが含まれていますjmp esp

実際には、プログラムには特定のレジスタにジャンプする命令が意図的に含まれていない場合があります。従来の解決策は、プログラム メモリ内のどこかの固定位置で、適切なオペコードの意図しないインスタンスを見つけることです。Eの左側は、i386 命令のそのような意図的でないインスタンスの例ですjmp espこの命令のオペコードは ですFF E4[12]call DbgPrintこの 2 バイトのシーケンスは、アドレス の命令の先頭から 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、Python など、厳密に型指定され、メモリへの直接アクセスが許可されていない言語では、ほとんどの場合、バッファ オーバーフローの発生を防ぎます。[15] C または C++ 以外の多くのプログラミング言語では、実行時チェックが提供されており、場合によってはコンパイル時チェックも提供されており、C または C++ がデータを上書きし、誤った結果が得られるまでさらなる命令の実行を続ける場合に、警告が送信されたり、例外が発生したりする可能性があります。これにより、プログラムがクラッシュする場合とそうでない場合があります。このような言語の例には、AdaEiffelLispModula-2SmalltalkOCaml 、およびCycloneなどの C 派生言語が含まれます。錆びD. _ Javaおよび.NET Framework のバイトコード環境は、すべての配列の境界チェックも必要です。ほぼすべてのインタープリタ言語は、明確に定義されたエラー状態を通知するバッファ オーバーフローから保護します。多くの場合、言語が境界チェックを行うのに十分な型情報を提供する場合、それを有効または無効にするオプションが提供されます。静的コード分析では、多くの動的な境界チェックや型チェックを削除できますが、実装が不十分であったり、扱いにくい場合は、パフォーマンスが大幅に低下する可能性があります。ソフトウェア エンジニアは、使用する言語とコンパイラ設定を決定する際に、安全性とパフォーマンス コストのトレードオフを慎重に考慮する必要があります。

安全なライブラリの使用

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

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

2007 年 9 月に、C 標準委員会によって作成されたテクニカル レポート 24731 が発行されました。[21]標準 C ライブラリの文字列および IO 関数に基づく一連の関数と、追加のバッファ サイズ パラメータを指定します。ただし、バッファ オーバーフローを軽減するという目的におけるこれらの関数の有効性には議論の余地があります。関数呼び出しごとにプログラマの介入が必要ですが、これは、類似の古い標準ライブラリ関数のバッファ オーバーフローを安全にする介入と同じです。[22]

バッファオーバーフロー保護

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

Microsoft のデータ実行防止(DEP) モードの実装は、構造化例外ハンドラー(SEH)へのポインターが上書きされないように明示的に保護します。[26]

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

ポインタの保護

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

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

実行可能領域の保護

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

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

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

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

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

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

アドレス空間レイアウトのランダム化

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

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

ディープパケットインスペクション

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

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

テスト

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

歴史

バッファ オーバーフローは、コンピュータ セキュリティ技術計画研究が次のような手法を発表した 1972 年にはすでに理解されており、部分的に公的に文書化されていました。「この機能を実行するコードは、ソース アドレスと宛先アドレスを適切にチェックせず、モニタの一部がオーバーレイされることを許可します。」これは、ユーザーがマシンの制御を掌握できるようにするコードをモニターに挿入するために使用できます。」[40]今日では、モニターはカーネルと呼ばれます。

バッファ オーバーフローの敵対的悪用が最も早く記録されたのは 1988 年です。これは、 Morris ワームがインターネット上で自身を増殖させるために使用したいくつかの悪用のうちの 1 つでした。悪用されたプログラムは、fingerと呼ばれるUnix上のサービスでした。[41]その後、1995 年に Thomas Lopatic が独自にバッファ オーバーフローを再発見し、その発見をBugtraqセキュリティ メーリング リストに公開しました。[42] 1年後の1996年、エリアス・レヴィ(アレフ・ワンとしても知られる)は「楽しみと利益のためにスタックを破壊する」という論文をプラック誌に発表した[43]スタックベースのバッファ オーバーフローの脆弱性を悪用する方法を段階的に紹介します。

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

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

こちらも参照

参考文献

  1. ^ R. シャーリー (2007 年 8 月)。インターネット セキュリティ用語集、バージョン 2。ネットワーク ワーキング グループ。土井: 10.17487/RFC4949RFC 4949。 情報提供。
  2. ^ "CORE-2007-0219: OpenBSD の IPv6 mbufs リモート カーネル バッファ オーバーフロー" . 2007 年 5 月 15 日に取得
  3. ^ 「最新のオーバーフロー ターゲット」(PDF)2022-10-09 にオリジナルからアーカイブ(PDF)されました2013 年 7 月 5 日に取得
  4. ^ 「Metasploit オペコード データベース」. 2007 年 5 月 12 日のオリジナルからアーカイブ2007 年 5 月 15 日に取得
  5. ^ 「Microsoft Technet セキュリティ情報 MS04-028」。マイクロソフト2011 年 8 月 4 日にオリジナルからアーカイブされました2007 年 5 月 15 日に取得
  6. ^ 「Unicode 拡張文字列での任意のシェルコードの作成」(PDF)2006 年 1 月 5 日にオリジナル(PDF)からアーカイブされました2007 年 5 月 15 日に取得
  7. ^ ヴァンゲリス (2004-12-08)。「スタックベースのオーバーフローエクスプロイト: 古典的および高度なオーバーフロー手法の紹介」。Neworder経由のWowhacker。2007年8月18日のオリジナル(テキスト)よりアーカイブ。 {{cite journal}}:引用ジャーナルが必要です|journal=(ヘルプ)
  8. ^ バラバン、ムラット。「バッファ オーバーフローの謎を解く」(テキスト)Enderunix.org。 {{cite journal}}:引用ジャーナルが必要です|journal=(ヘルプ)
  9. ^ アクリティディス、P.; エヴァンゲロス・P・マルカトス。M.ポリクロナキス。コスタス D. アナグノスタキス (2005)。「STRIDE: 命令シーケンス分析による多態性スレッドの検出」(PDF)第 20 回 IFIP 国際情報セキュリティ会議 (IFIP/SEC 2005) の議事録IFIP 国際情報セキュリティ会議。2012 年 9 月 1 日にオリジナル(PDF)からアーカイブされました2012 年 3 月 4 日に取得
  10. ^ クリスチャン、クライン (2004 年 9 月)。「バッファオーバーフロー」(PDF)2007 年 9 月 28 日のオリジナル(PDF)からアーカイブされました。 {{cite journal}}:引用ジャーナルが必要です|journal=(ヘルプ)
  11. ^ シャー、サウミル (2006)。「Metasploit プラグインの作成: 脆弱性から悪用まで」(PDF)ハックインザボックスクアラルンプール2012 年 3 月 4 日に取得
  12. ^ Intel 64 および IA-32 アーキテクチャ ソフトウェア開発者マニュアル、第 2 巻 A: 命令セット リファレンス、AM (PDF)インテル株式会社 2007 年 5 月、3–508 ページ。2007 年 11 月 29 日にオリジナル(PDF)からアーカイブされました。
  13. ^ アルバレス、セルヒオ (2004-09-05)。「Win32 Stack BufferOverFlow Real Life Vuln-Dev Process」(PDF)ITセキュリティコンサルティング2012 年 3 月 4 日に取得 {{cite journal}}:引用ジャーナルが必要です|journal=(ヘルプ)
  14. ^ 鵜飼裕二; デレク・ソーダー。パーメ、ライアン (2004)。「Windows エクスプロイトにおける環境依存関係」。ブラックハットジャパン日本: eEye デジタル セキュリティ2012 年 3 月 4 日に取得
  15. ^ ab https://www.owasp.org/index.php/Buffer_Overflows OWASP に関するバッファ オーバーフローの記事、2016 年 8 月 29 日にウェイバック マシンにアーカイブ
  16. ^ "vector::at - C++ リファレンス". Cplusplus.com 2014 年 3 月 27 日に取得
  17. ^ 「アーカイブされたコピー」。盗聴.エリア.com2001 年 5 月 5 日のオリジナルからアーカイブ2022 年6 月 6 日に取得{{cite web}}: CS1 メイン: タイトルとしてアーカイブされたコピー (リンク)
  18. ^ 「より良い文字列ライブラリ」.
  19. ^ “Vstr ホームページ”. 2017-03-05 のオリジナルからアーカイブ2007 年 5 月 15 日に取得
  20. ^ “エルヴィンのホームページ” . 2007 年 5 月 15 日に取得
  21. ^ 国際標準化機構 (2007)。「情報技術 – プログラミング言語、その環境、およびシステム ソフトウェア インターフェイス – C ライブラリの拡張 – パート 1: 境界チェック インターフェイス」。ISO オンライン ブラウジング プラットフォーム
  22. ^ 「CERT セキュア コーディング イニシアチブ」. 2012 年 12 月 28 日のオリジナルからアーカイブ2007 年 7 月 30 日に取得
  23. ^ "FSF.org の Libsafe" . 2007 年 5 月 20 日に取得
  24. ^ 「StackGuard: バッファ オーバーフロー攻撃の自動適応検出と防止、Cowan らによる」(PDF)2022-10-09 にオリジナルからアーカイブ(PDF)されました2007 年 5 月 20 日に取得
  25. ^ “X.ORG のプロポリス”. 2007 年 2 月 12 日のオリジナルからアーカイブ2007 年 5 月 20 日に取得
  26. ^ "Windows ハードウェアによるデータ実行防止のバイパス". 2007 年 4 月 30 日にオリジナルからアーカイブされました2007 年 5 月 20 日に取得
  27. ^ “第 12 回 USENIX セキュリティ シンポジウム – テクニカル ペーパー”. www.usenix.org 2018 年4 月 3 日に取得
  28. ^ “ポインターごまかしに対する保護 (ちょっと!)”. msdn.com2010 年 5 月 2 日にオリジナルからアーカイブされました2018 年4 月 3 日に取得
  29. ^ 「USENIX - アドバンスト コンピューティング システム協会」(PDF)www.usenix.org2022-10-09 にオリジナルからアーカイブ(PDF)されました2018 年4 月 3 日に取得
  30. ^ "ポインタごまかしに対する保護 (Redux)". msdn.com2009 年 12 月 19 日にオリジナルからアーカイブされました2018 年4 月 3 日に取得
  31. ^ "PaX: PaX チームのホームページ" . 2007 年 6 月 3 日に取得
  32. ^ "KernelTrap.Org". 2012 年 5 月 29 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得
  33. ^ "Openwall Linux カーネル パッチ 2.4.34-ow1". 2012 年 2 月 19 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得
  34. ^ "Microsoft Technet: データ実行防止". 2006 年 6 月 22 日にオリジナルからアーカイブされました2006 年 6 月 30 日に取得
  35. ^ "BufferShield: Windows のバッファ オーバーフロー悪用の防止" . 2007 年 6 月 3 日に取得
  36. ^ "NGSec スタック ディフェンダー". 2007 年 5 月 13 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得
  37. ^ "GRSecurity.net の PaX" . 2007 年 6 月 3 日に取得
  38. ^ "悪用者 - セキュリティ情報とチュートリアル" . 2009 年 11 月 29 日に取得
  39. ^ デヴィッド・ラロシェル; デヴィッド・エヴァンス(2001年8月13日)。「バッファ オーバーフローの可能性のある脆弱性を静的に検出する」。USENIX セキュリティ シンポジウム32
  40. ^ 「コンピュータセキュリティ技術計画調査」(PDF) . p. 61. 2011 年 7 月 21 日にオリジナル(PDF)からアーカイブされました2007 年 11 月 2 日に取得
  41. ^ “「ワームのツアー」、ドン・シーリー著、ユタ大学”. 2007 年 5 月 20 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得
  42. ^ "Bugtraq セキュリティ メーリング リスト アーカイブ". 2007 年 9 月 1 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得
  43. ^ "「楽しみと利益のためにスタックを破壊する」 by Aleph One" . 2012 年 9 月 5 日に取得
  44. ^ 「eEye デジタル セキュリティ」. 2007 年 6 月 3 日に取得
  45. ^ 「Microsoft Technet セキュリティ情報 MS02-039」。マイクロソフト2008 年 3 月 7 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得
  46. ^ “ハッカーが MOD チップなしで Xbox の保護を破る”. 2007 年 9 月 27 日にオリジナルからアーカイブされました2007 年 6 月 3 日に取得

外部リンク

  • 「FTP サーバーのリモート バッファ オーバーフローの脆弱性の発見と悪用」 by Raykoid666
  • 「楽しみと利益のためにスタックを破壊する」 by Aleph One
  • ゲルグ、アイザック (2005-05-02)。「バッファ オーバーフロー エクスプロイトの概要と例」(PDF)IAニュースレター情報保証技術分析センター7 (4): 16-21。2006 年 9 月 27 日にオリジナル(PDF)からアーカイブされました2019年3月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、ベッドフォード、マサチューセッツ州 01731 (1972 年 10 月) [NTIS AD-758 206]
  • 『バッファ オーバーフロー: エクスプロイトの構造』Nevermore 著
  • GCC および GLibc を使用した安全なプログラミング 2008 年 11 月 21 日にウェイバック マシンにアーカイブ(2008)、Marcel Holtmann 著
  • 「バッファオーバーフローによる悪用の危険 – パート 0 – テオリアの危険」 (2018)、Helvio Junior (M4v3r1ck) 著