バッファオーバーフロー

C言語で記述された以下の例では、プログラムにはメモリ上で隣接する2つの変数があります。8バイト長の文字列バッファaと、2バイトのビッグエンディアン整数ですb。

char a [ 8 ] = "" ; unsigned short b = 1979 ;

初期状態では、a0バイトしか含まれておらず、b数値1979が含まれています。

次に、プログラムはASCIIエンコーディングのヌル終端文字列を Aバッファに格納しようとします。"excessive"

strcpy ( a , "excessive" );

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

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

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

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

strlcpy ( a , "excessive" , sizeof ( a ));

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

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

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

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

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

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

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

実際の攻撃においては、攻撃が確実に機能するためには、克服すべき様々な課題が存在する。これらの課題には、アドレス内のヌルバイト、シェルコードの位置のばらつき、環境間の違い、そして様々な対策の実施などが含まれる。

NOPスレッドテクニック

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

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

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

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

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

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

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

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

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

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

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

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

2007 年 9 月、C 標準化委員会が作成した技術報告書 24731 が発行されました。^{[ 23 ]}この報告書では、標準 C ライブラリの文字列関数と IO 関数をベースに、バッファ サイズ パラメータを追加した一連の関数が規定されています。しかし、これらの関数がバッファ オーバーフローを減らすのにどれほど効果的かは議論の余地があります。これらの関数は、関数呼び出しごとにプログラマの介入を必要としますが、これは、類似の古い標準ライブラリ関数をバッファ オーバーフローに対して安全にする介入と同等です。^{[ 24 ]}

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

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

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

この種の保護は、すべての攻撃を検出するわけではないため、完全に正確ではありません。StackGuardのようなシステムは、攻撃の挙動に重点を置いているため、範囲チェックシステムと比較して効率的で高速です。^{[ 29 ]}

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

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

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

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

一部のUnix系オペレーティングシステム（OpenBSD、macOSなど）には、実行可能領域保護（W^Xなど）が標準搭載されています。オプションパッケージには以下のようなものがあります。

• PaX ^{[ 34 ]}
• エグゼクティブシールド^{[ 35 ]}
• オープンウォール^{[ 36 ]}

Microsoft Windowsの新しいバージョンでは、データ実行防止と呼ばれる実行可能領域保護もサポートされています。^{[ 37 ]}独自の追加機能には以下が含まれます。

• BufferShield ^{[ 38 ]}
• StackDefender ^{[ 39 ]}

実行可能領域保護は、一般的に、libcへのリターン攻撃や、攻撃者のコードの実行に依存しないその他の攻撃を防ぐものではありません。しかし、後述するように、 ASLRを使用する64ビットシステムでは、実行可能領域保護によって、そのような攻撃を実行することがはるかに困難になります。

CHERI（Capability Hardware Enhanced RISC Instructions）は、セキュリティ向上を目的としたコンピュータプロセッサ技術です。ハードウェアレベルで動作し、メモリへのアクセスを許可するハードウェア強制型（CHERI機能）を提供します。従来のポインタは、特定のポインタを介してアクセスできる範囲を制限するメタデータ付きのアドレスに置き換えられます。

アドレス空間配置ランダム化（ASLR）は、コンピュータのセキュリティ機能の一つで、通常は実行ファイルのベースアドレス、ライブラリ、ヒープ、スタックの位置など、重要なデータ領域の位置をプロセスのアドレス空間内でランダムに配置するものです。

関数や変数が見つかる仮想メモリアドレスをランダム化することで、バッファ オーバーフローの悪用はより困難になりますが、不可能になるわけではありません。また、攻撃者は個々のシステムに合わせて悪用を試みなければならなくなるため、インターネット ワームの試みを阻止できます。^{[ 40 ]}同様の方法ですが、効果は劣ります。プロセスとライブラリを仮想アドレス空間に再配置する方法もあります。

ディープパケットインスペクション（DPI）を使用すると、ネットワーク境界で、攻撃シグネチャとヒューリスティックを用いてバッファオーバーフローを悪用しようとする非常に基本的なリモート攻撃を検出できます。この技術は、既知の攻撃のシグネチャを持つパケットをブロックできます。以前は、一連の無操作命令（NOPスレッドとして知られる）が検出され、エクスプロイトのペイロードの位置がわずかに変動する場合に使用されていました。

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

バッファオーバーフローをチェックし、それを引き起こすバグを修正することで、バッファオーバーフローを防ぐことができます。バッファオーバーフローを検出するための一般的な自動化手法の 1 つはファジングです。^{[ 41 ]}エッジケーステストでもバッファオーバーフローを発見できますし、静的解析でも発見できます。^{[ 42 ]}バッファオーバーフローの可能性が検出されたら、修正する必要があります。このテスト手法は開発中のソフトウェアには有効ですが、保守やサポートが終了しているレガシーソフトウェアにはあまり有効ではありません。