セキュリティホールの仕組み：バッファオーバーフロー

ご注意 トランスレータ： これは、Peter Brightの記事「セキュリティの欠陥の仕組み：バッファオーバーフロー」の翻訳です。バッファオーバーフローの仕組みと、脆弱性と保護方法の開発方法についてです 。

1988年のMorris Wormから、この問題はLinuxとWindowsの両方に影響を与えました。







バッファオーバーフローは、コンピュータセキュリティの分野で長い間知られています。 最初の自己増殖インターネットワームである1988 Morris Wormでさえ、フィンガーUnixデーモンのバッファオーバーフローを使用してマシン間で拡散しました。 27年後、バッファオーバーフローは依然として問題の原因です。 Windows開発者は、2000年代の初めに2つのエクスプロイトベースのバッファオーバーフローが発生した後、セキュリティへのアプローチを変更しました。 また、 今年5月に （潜在的に）発見されたLinuxドライバーのバッファーオーバーフローにより、数百万のホームルーターおよびSMBルーターが攻撃にさらされています。



本質的に、バッファオーバーフローは、一般的な慣行に起因する非常に単純なバグです。 コンピュータプログラムは、多くの場合、ディスク、ネットワーク、またはキーボードから読み取られたデータのブロックで動作します。 このデータを割り当てるために、プログラムは有限サイズのメモリブロック-バッファを割り当てます。 バッファのオーバーフローは、バッファが保持できるよりも大きいデータボリュームを読み書きするときに発生します。



表面的には、それは非常に愚かな間違いのように見えます。 最終的に、プログラムはバッファのサイズを認識します。つまり、プログラムがバッファに既知のサイズを超えて配置しようとしないことを簡単に確認できるはずです。 そして、あなたはこのように推論するのが正しいでしょう。 ただし、バッファオーバーフローは引き続き発生し、その結果は多くの場合、セキュリティ上の障害となります。



バッファオーバーフローが発生する理由と、結果が非​​常に悲惨な理由を理解するには、プログラムがメモリを使用する方法とプログラマがコードを記述する方法を考慮する必要があります。



（著者のメモ：スタックバッファオーバーフローを主に考慮します。これは、オーバーフローの唯一のタイプではありませんが、古典的で最も研究されているタイプです）

スタック

バッファオーバーフローは、ネイティブコードでのみ問題を引き起こします。 JavaやPythonなどの仲介なしで、一連のプロセッサ命令を直接使用するプログラムで。 オーバーフローは、ネイティブコードのプロセッサとプログラムがメモリを管理する方法に関連しています。 異なるオペレーティングシステムには独自の特性がありますが、最新の一般的なプラットフォームはすべて一般的な規則に従います。 攻撃がどのように機能し、どのように対抗するかを理解するために、最初にメモリ使用量を少し見てみましょう。



最も重要な概念は、メモリ内のアドレスです。 メモリの各バイトには、対応する数値アドレスがあります。 プロセッサは、メインメモリ（RAM、RAM）に対してデータの読み取りまたは書き込みを行うとき、読み取りが行われた場所または書き込みが行われた場所のメモリアドレスを使用します。 システムメモリはデータに使用されるだけではありません。 また、プログラムを構成する実行可能コードをホストするためにも使用されます。 つまり、実行中のプログラムの各機能にもアドレスがあります。



当初、プロセッサとオペレーティングシステムは物理メモリアドレスを使用していました。各メモリアドレスは、特定のRAMのアドレスに直接関連付けられていました。 最新のオペレーティングシステムの一部ではまだ物理アドレスが使用されていますが、最新のオペレーティングシステムはすべて仮想メモリと呼ばれるスキームを使用しています。



仮想メモリを使用する場合、メモリアドレスと物理RAM部分の直接的な対応はありません。 代わりに、プログラムとプロセッサは仮想アドレス空間で動作します。 オペレーティングシステムとプロセッサは、仮想メモリアドレスと物理メモリアドレス間のマッピングを共同でサポートします。



この仮想化により、いくつかの重要な機能を使用できます。 最初で最も重要なのは、 保護されたメモリです。 個々のプロセスはそれぞれ独自のアドレスのセットを受け取ります。 32ビットプロセスの場合、アドレスはゼロ（最初のバイト）から始まり、4,294,967,295（16進数では0xffff'ffff; 2 ^ 32-1）までになります。 64ビットプロセスの場合、アドレスは18,446,744,073,709,551,615（0xffff'ffff'ffff'ffff、2 ^ 64-1）まで続きます。 したがって、各プロセスには独自のアドレス0があり、その後にアドレス1、アドレス2などが続きます。



（著者のメモ：この記事の残りの部分では、特に明記しない限り、32ビットシステムについて説明します。この側面では、32ビットと64ビットの違いは重要ではありません。明確にするために、1ビットを厳守します）



各プロセスは独自のアドレスセットを受け取るので、このスキームは、あるプロセスから別のプロセスへのメモリ破損を防ぐ簡単な方法です。プロセスがアクセスできるすべてのアドレスは、そのプロセスのみに属します。 これは、プロセス自体にとってはるかに簡単です。 物理メモリアドレスは、広い意味では機能しますが（これらはゼロから始まる数字です）、使用するのに多少不便な機能があります。 たとえば、通常は非連続です。 たとえば、アドレス0x1ff8'0000は、プロセッサのシステム制御モードのメモリに使用されます。これは、通常のプログラムではアクセスできない小さなメモリです。 PCIeカードのメモリもこのスペースにあります。 仮想メモリアドレスでは、このような不便はありません。



プロセスのアドレス空間には何がありますか？ 一般的に、4つの共通オブジェクトがあり、そのうちの3つが興味を持っています。 ほとんどのオペレーティングシステムで私たちにとって興味のないブロックは、「オペレーティングシステムの中核」です。 パフォーマンスのために、アドレス空間は通常2つの半分に分割され、その下半分はプログラムによって使用され、上半分はカーネルのアドレス空間によって占有されます。 カーネルに与えられた半分は、プログラムが占有している半分からは利用できませんが、カーネル自体はプログラムメモリを読み取ることができます。 これは、カーネル関数にデータを渡す1つの方法です。



まず、実行可能部分とプログラムを構成するライブラリを扱います。 メインの実行可能ファイルとそのすべてのライブラリはプロセスのアドレス空間にロードされ、それらを構成するすべての関数はメモリ内にアドレスを持ちます。



プログラムが使用するメモリの2番目の部分は、処理されたデータを格納するために使用され、通常はヒープと呼ばれます 。 たとえば、この領域は、編集されたドキュメント、表示されたWebページ（すべてのJavaScritオブジェクト、CSSなどを含む）、またはプレイされているゲームのマップを格納するために使用されます。



3番目の最も重要な部分は呼び出しスタックであり、通常は単にスタックと呼ばれます。 これが最も難しい側面です。 プロセス内の各スレッドには独自のスタックがあります。 これは、ストリームで実行可能な現在の関数と以前のすべての関数（現在の関数に入るために呼び出された関数）の両方を同時に追跡するために使用されるメモリ領域です。 たとえば、関数aが関数bを呼び出し、関数bが関数cを呼び出す場合、スタックにはa 、 b、およびcに関する情報がこの順序で含まれます。



呼び出しスタックは、「スタック」と呼ばれるデータ構造の特殊バージョンです。 スタックは、オブジェクトを格納するための可変長構造です。 新しいオブジェクトをスタックの最後（通常、スタックの「トップ」と呼ばれる）にプッシュし、スタックからオブジェクトをポップできます。 スタックの最上部のみがプッシュとポップを使用して変更されるため、スタックは厳密なソート順を確立します。スタックに最後に配置されたオブジェクトが次にスタックから削除されます。



呼び出しスタックに保存される最も重要なオブジェクトは、リターンアドレスです。 ほとんどの場合、プログラムが関数を呼び出すと、この関数は必要な処理（他の関数の呼び出しを含む）を実行し、呼び出した関数に制御を返します。 呼び出し関数に戻るには、その関数に関するレコードを保存する必要があります。呼び出し命令に続く命令で実行を継続する必要があります。 この命令のアドレスは、リターンアドレスと呼ばれます。 スタックは、これらのリターンアドレスを格納するために使用されます。関数が呼び出されるたびに、リターンアドレスがスタックに配置されます。 各リターンで、アドレスはスタックから削除され、プロセッサはこのアドレスで命令の実行を開始します。



スタック機能は非常に基本的で必要なため、すべてではないにしても、ほとんどのプロセッサにこれらの概念のサポートが組み込まれています。 例としてx86プロセッサを取り上げます。 x86仕様で定義されているレジスタ（命令にアクセス可能なプロセッサのメモリの小さな領域）のうち、最も重要な2つはeip （命令ポインタ）とesp （スタックポインタ）です。



ESPには常にスタックの最上位のアドレスが含まれます。 何かがスタックにプッシュされるたびに、esp値は減少します。 スタックから何かが削除されるたびに、esp値が増加します。 これは、スタックが「ダウン」していることを意味します。 オブジェクトがスタックに追加されると、espに保存されるアドレスはますます小さくなります。 それにもかかわらず、espが指すメモリ領域は「スタックのトップ」と呼ばれます。

ここでは、 nameという名前の 64文字のバッファーを使用したスタックの単純なスキャンに続いて、フレームポインター、リターンアドレスが表示されています。 espレジスタには頂点のアドレスが含まれ、 ebpにはフレームポインターのアドレスが含まれます。

EIPには、現在の命令のアドレスが含まれます。 プロセッサは、独自にeip値をサポートします。 メモリから命令ストリームを読み取り、それに応じてeip値を変更するため、常に命令のアドレスが含まれます。 x86内には、関数callを呼び出すための命令と 、 -retを返すための命令があります。



CALLは、呼び出される関数のアドレスという1つのオペランドを受け入れます（ただし、渡す方法はいくつかあります）。 呼び出しが行われると、espスタックポインターが4バイト（32ビット）減り、呼び出しに続く命令アドレス（戻りアドレス）がespが指すメモリ領域に配置されます。 つまり、リターンアドレスがスタックにプッシュされます。 次に、eip値が呼び出しオペランドとして渡されたアドレスと等しく設定され、この時点から実行が継続されます。



RETは逆の操作を実行します。 Simple retはオペランドを受け入れません。 プロセッサは最初にespに格納されているメモリアドレスの値を読み取り、次にespを4バイト増やします-スタックから戻りアドレスを削除します。 値はeipに配置され、実行はこのアドレスから継続されます。

（翻訳者注：著者のテキストのこの時点で、 呼び出しと再試行を示すビデオがあります。 ）

呼び出しスタックが戻りアドレスのセットのみを保持している場合、問題はありません 。 本当の問題は、スタックにプッシュされる他のすべてのものにあります。 スタックは、データを保存するための高速で効率的な場所であることがわかりました。 ヒープにデータを保存することは比較的困難です。プログラムは、ヒープで使用可能なスペース、各オブジェクトが占める量などを追跡する必要があります。 同時に、スタックの操作は簡単です。小さなデータを配置するには、ポインターの値を単純に減らすだけで十分です。 そして、自分でクリーンアップするには、ポインタの値を増やすだけです。



この利便性により、スタックは、関数で使用される変数を配置する論理的な場所になります。 関数はユーザー入力を受け入れるために256バイトのバッファーを必要としますか？ 簡単です。スタックポインタから256を引くだけで、バッファの準備が整います。 関数の最後で、ポインタに256を追加するだけで、バッファは破棄されます。



ただし、このアプローチには制限があります。 スタックは、非常に大きなオブジェクトの保存には適していません。使用可能なメモリの総量は、通常、ストリームの作成時に固定され、多くの場合、ボリュームが約1MBです。 したがって、大きなオブジェクトはヒープに配置する必要があります。 スタックは、呼び出された関数が実行されるよりも長く存在する必要があるオブジェクトにも適用できません。 関数が終了するとスタック上のすべての割り当てが削除されるため、スタック上のオブジェクトの寿命は対応する関数の実行時間を超えません。 ヒープ上のオブジェクトの場合、この制限は適用されず、永久に存在する可能性があります。

プログラムを正しく使用すると、キーボード入力は名前バッファに格納され、nullのゼロバイトで閉じられます。 フレームポインターと戻りアドレスは変更されません。

スタックストレージは、プログラマが明示的に定義した変数だけでなく、使用されます。 スタックは、プログラムで必要な値を格納するためにも使用されます。 これは、x86で特に深刻です。 X86ベースのプロセッサは、多数のレジスタで違いはありません（合計8個の整数レジスタがあり、既に言及したeipやespのように、それらの一部は既に使用されています）。 レジスターのスペースを解放するために、後で使用するために値を保持しながら、コンパイラーはレジスターの値をスタックにプッシュします。 後でレジスタから値を削除して、レジスタに戻すことができます。 コンパイラーの専門用語では、レジスターを保管して、後で使用する可能性のあるプロセスをスピルと呼びます。



最後に、スタックは関数に引数を渡すためによく使用されます。 呼び出し側の関数は、各引数をスタックにプッシュします。 呼び出された関数はそれらをスタックから削除できます。 これは引数を渡す唯一の方法ではありません-たとえば、レジ​​スタを使用できます-しかし、最も柔軟な方法の1つです。



スタック上の関数によって格納されるオブジェクトのセット—独自の変数、格納されたレジスタ、他の関数への送信のために準備された引数—は、「ネストされたフレーム」と呼ばれます。 接続されたフレームのデータは積極的に使用されるため、単純にアドレス指定する方法があると便利です。



スタックポインターを使用してこれを実装することは可能ですが、多少不便です。スタックポインターは常に最上部を指し、オブジェクトの配置と削除に応じて値が変化します。 たとえば、変数は最初に位置esp + 4に配置されます。 さらに2つの値がスタックに配置された後、変数はesp + 12に配置され始めました。 スタックから値の1つを削除すると、変数はesp + 8になります。



説明されていることは不可能な作業ではなく、コンパイラーはそれに対処することができます。 ただし、これにより、特にアセンブラーを手動で記述する場合に、スタックポインターを使用して頂点の「ダム」以外にアクセスできます。



タスクを簡素化するために、各フレームの「ボトム」アドレス（つまり、先頭）を格納する2番目のポインター（フレームポインターと呼ばれる値）を保持するのが一般的です。 また、x86には、通常ebpに使用されるレジスタもあります。 その値は常に関数内にあるため、関数変数を明確にアドレスする方法があります。ebp-4の値は、関数の存続期間を通してebp-4で利用可能なままです。 そして、これは人々だけでなく、デバッガーが何が起こっているかを把握するのが簡単です。

Visual Studioのスクリーンショットは、例として単純なx86プログラムを使用して、これらすべての動作を示しています。 x86プロセッサでは、 espレジスタにはスタックの最上部のアドレスが含まれ、この場合は0x0019fee0 （青で強調表示）です。 （ 著者の注記：x86プラットフォームでは、スタックはメモリアドレス0の方向に成長しますが、このポイントは「スタックのトップ」という名前を保持します ）。 表示される関数は、スタック上でピンク色で強調表示された変数名のみを保存します。 これは、長さが64バイトの固定バッファーです。 これは唯一の変数であるため、そのアドレスも0x0019fee0であり、スタックの最上部と同じです。



X86には、赤で強調表示されたebpレジスタもあり、これは（通常）フレームポインタを格納するために割り当てられます。 フレームポインターは、スタック変数の直後にあります。 フレームポインターのすぐ後ろに、緑色で強調表示された戻りアドレスがあります。 リターンアドレスは、 0x00401048のコードを参照します。 この命令は呼び出しの直後に続き、プログラムが呼び出し関数を離れた場所で実行を継続するために戻りアドレスがどのように使用されるかを示します。

上の図のNAMEは、定期的にオーバーフローするバッファの種類を具体的に示しています。 サイズは64バイトに固定されています。 この場合、数字のセットで埋められ、ゼロで終わります。 この図は、ネームバッファに64バイト以上が書き込まれると、スタック内の他の値が破損することを示しています。 さらに4バイトを書き込むと、フレームポインターは破棄されます。 さらに8バイトを書き込むと、フレームポインターと戻りアドレスが上書きされます。



明らかに、これはデータの破損につながりますが、バッファオーバーフローの問題はより深刻です。[任意の]コードの実行につながります。 これは、バッファオーバーフローがデータを上書きするだけではないためです。 スタックに格納されているより重要なもの（返信先アドレス）も上書きされる場合があります。 リターンアドレスは、現在の関数が終了したときにプロセッサが実行する命令を制御します。 これは呼び出し関数内のある種のアドレスであると想定されていますが、この値がバッファオーバーフローによって上書きされた場合、どこでも指すことができます。 攻撃者がバッファオーバーフローを制御できる場合、リターンアドレスを制御できます。 戻りアドレスを制御する場合、次に何をすべきかをプロセッサに伝えることができます。



ほとんどの場合、プロセッサには、攻撃者が起動する「マシンを妥協する」美しい便利な機能はありませんが、これはそれほど重要ではありません。 リターンアドレスを変更するために使用されるのと同じバッファーを使用して、実行可能なコード（シェルコード、シェルコード）の小さな断片を保存し、悪意のある実行可能ファイルをダウンロードするか、ネットワーク接続を開くか、攻撃者の他の希望を満たすことができます。



従来、これを行うのは簡単でした。多くの人が驚いた理由からです。通常、マシンを再起動しても、すべてのプログラムは起動するたびにメモリ内の同じアドレスを使用します。 これは、スタック上のバ​​ッファの位置が毎回同じになるため、戻りアドレスを歪めるために使用される値が毎回同じになることを意味します。 攻撃者はこのアドレスを1回見つけるだけでよく、攻撃は脆弱なコードを実行するすべてのコンピューターで機能します。

攻撃者ツールキット

理想的な世界では-攻撃者の観点から-書き換えられたリターンアドレスは、単にバッファアドレスである可能性があります。 また、プログラムがファイルまたはネットワークからデータを読み取る場合、これは非常に可能です。



それ以外の場合、攻撃者はトリックを行う必要があります。 人間が読めるテキストを処理する関数では、多くの場合、nullバイトには特別な意味があります。 このようなバイトは行の終わりを示し、行を操作するために使用される関数（コピー、比較、結合）が停止します。 彼らがこのシンボルに出会ったとき。 これは、シェルコードにゼロが含まれている場合、これらのプロシージャがそれを壊すことを意味します。

（翻訳者のメモ：著者のテキストのこの時点で、 オーバーフローを示すビデオがあります。その中に、シェルコードがバッファーに入れられ、リターンアドレスが書き換えられます。シェルコードは標準のWindows計算機を起動します。）

これを回避するために、攻撃者はさまざまなトリックを使用できます。 ゼロを含むシェルコードを問題のあるバイトを回避する同等のシーケンスに変換する小さなコード。 したがって、非常に厳しい制限をクロールすることもできます。 たとえば、脆弱な機能は、標準キーボードから入力できるデータのみを受け入れます。



実際、スタックアドレスには多くの場合ゼロが含まれ、同様の問題があります。これは、スタックバッファからリターンアドレスに書き込むことができないことを意味します。バッファ自体を埋める（およびオーバーフローする可能性がある）ために使用される関数の一部がゼロを書き込むため、これは怖くない場合があります。いくつかの注意を払って、リターンアドレスにスタックアドレスを設定することにより、ヌルバイトを正しい場所に正確に配置するために使用できます。



しかし、これが不可能な場合でも、状況は迂回（迂回）で回避されます。実際、すべてのライブラリを備えたプログラムは、メモリ内に大量の実行可能コードを保持しています。このコードのほとんどには、「安全な」アドレスがあります。アドレスにゼロは含まれません。



次に、攻撃者はcall espなどの命令を含む適切なアドレスを見つける必要があります。（x86）、関数のアドレスとしてスタックポインターの値を使用し、その実行を開始します。これは、スタックバッファーに隠されたシェルコードに最適です。攻撃者はcall esp命令のアドレスを使用して、リターンアドレスとして書き込みます。プロセッサはこのアドレスをさらにジャンプしますが、それでもシェルコードに到達します。別のアドレスをジャンプするこの手法は、「スプリングボード」と呼ばれます。

オーバーフローを悪用するために、攻撃者は特定の文字ですべてを詰まらせるのではなく、バッファシェルコードに書き込みます。これは、攻撃者が選択したアクションを実行する実行可能コードの短いセクションです。戻りアドレスは、バッファからの対応するアドレスで書き換えられ、プロシージャから戻るときにプロセッサにシェルコードの実行を強制します。

繰り返しますが、これはプログラムとそのライブラリーが各起動時に同じメモリー領域に配置されるためです-リブート間でも、異なるマシン上でも。この問題で興味深い点の1つは、スプリングボードを実行するライブラリがcall esp演算子を使用する必要さえないことです。 2つの適切なバイトが含まれていれば十分です（この場合、値0xffおよび0xd4）次々に行きます。それらは、他の機能の一部である場合も、単なる数字の一部である場合もあります。 x86はそのようなことを気にしません。 X86命令は非常に長く（最大15バイト！）、任意のアドレスに配置できます。プロセッサが、たとえば4バイト命令の2番目のバイトなど、中央から命令の読み取りを開始すると、結果は完全に異なるがまだ有効な命令として解釈されます。この状況により、便利なジャンプを簡単に見つけることができます。



ただし、場合によっては、攻撃がリターンアドレスを正確に設定できないことがあります。必要な場所。メモリ内のオブジェクトの場所は非常に似ていますが、マシンごとに、または開始ごとにわずかに異なる場合があります。たとえば、攻撃されたバッファの正確な場所は、システムの名前またはIPアドレスに応じて、またはマイナーなプログラムの更新によりマイナーな変更が行われたために、数バイト上下に変化する場合があります。これに対処するには、ほぼ正しい返送先アドレスを指定できると便利ですが、高い精度は必要ありません。



これは、「ランディングストリップ」（NOPスレッド、点灯。「NOPスレッド」（Haltに感謝）正確なロシア語の用語-約）。攻撃者は、シェルコードをバッファに直接書き込む代わりに、実際のシェルコードの前に、時には何百ものNOP命令（「no-op」、つまり操作の不在-プロセッサに何もしないように指示する）を書き込みます。シェルコードを起動するには、攻撃者はこれらのNOPの中央のどこかにリターンアドレスを設定する必要があります。そして、NOPの分野に入ると、プロセッサはそれらを迅速に処理し、実際のシェルコードに進みます。

戻りアドレスをバッファのアドレスで書き換えることは難しい場合があります。解決策として、被害先プログラム（またはそのライブラリ）の実行可能コードの一部のアドレスでリターンアドレスを書き換えることができます。そして、このフラグメントはすでに制御をバッファに転送します。

C Blame Everything

これをすべて可能にする主なバグ-使用可能なスペースよりも多くのバッファに書き込む-は、簡単に回避できるもののように見えます。 Cプログラミング言語、または多かれ少なかれ互換性のある子孫、特にC ++とObjective Cを非難するのは誇張です（小さいながらも）。C言語は古く、広く使用されており、オペレーティングシステムとプログラムに必要です。その設計は嫌で、これらのバグはすべて回避できますが、Cは不注意をキャッチするためにすべてを行います。



安全な開発に対するCの敵意の例として、gets（）関数を見てください。この関数は1つのパラメーター-バッファー-を取り、標準入力（通常は「キーボード」を意味します）からデータの行を読み取り、それをバッファーに入れます。注意深く見ると、関数がgets（）にはバッファサイズパラメータが含まれておらず、C設計の楽しい事実として、gets（）関数がそれ自体でバッファサイズを決定する方法はありません。これは、gets（）の場合、単に問題ではないためです。キーボードの人がEnterキーを押すまで、関数は標準入力から読み取ります。次に、この人がバッファに収まらないほど多く入力した場合でも、関数はこのすべてをバッファにプッシュしようとします。



これは、文字通り安全に使用できない関数です。キーボードから入力されるテキストの量を制限する方法がないため、gets（）関数でバッファオーバーフローを防ぐ方法はありません。 C言語標準の作成者はすぐに問題を認識しました。 C仕様putの1999バージョンでは（）が流通しなくなり、2011アップデートでは完全に削除されます。しかし、その存在（および定期的な使用）は、Cがユーザーに対してどのようなトラップを持っているかを示しています。



Morrisのワームは、1988年に数日で初期のインターネットをクロールした最初の自己拡散型マルウェアであり、この機能を悪用しました。BSD 4.3 のfingerdプログラムは、ネットワークポート79、fingerポートでリッスンします。指Unix用の古代のプログラムであり、リモートシステムにログオンしているユーザーを見つけるために使用される対応するネットワークプロトコルです。2つの使用例があります。リモートシステムに問い合わせて、ログインしているすべてのユーザーを見つけるか、特定のユーザー名を要求すると、プログラムはユーザーに関する情報を返します。

残念ながら、gets（）は非常に愚かな関数です。キーボードのAキーを押し続けるだけで十分で、名前バッファーを埋めた後も停止しません。彼女は引き続きメモリにデータを書き込み、フレームポインター、リターンアドレス、および到達可能な他のすべてを上書きします。

fingerデーモンネットワークに接続するたびに、gets（）を使用してネットワークから512バイトのスタックバッファーへの読み取りを開始しました。通常の操作中、fingerdはfingerプログラムを実行し、ユーザー名（存在する場合）を渡します。 fingerプログラムは、ユーザーを列挙したり、特定のユーザーに関する情報を提供したりする実際の仕事をしました。 Fingerdは、単にネットワーク接続とfingerの起動を担当していました。



唯一の「実際の」パラメーターがオプションのユーザー名である場合、512バイトはかなり大きなバッファーです。おそらく、誰もユーザー名を持たず、この長さに近いでしょう。ただし、システム内のどこにも、ひどいgets（）関数があるためにこの制限が厳しくありませんでした。ネットワーク経由で512バイト以上を送信すると、fingerdはバッファーをオーバーフローさせます。そして、これはまさにロバート・モリスがやったことです：彼のエクスプロイトは537バイトをfingerdに送信し（536バイトのデータとラインフィードにより読み取りを停止しました）、バッファーをオーバーフローさせ、リターンアドレスを書き換えました。戻りアドレスは、単にスタックバッファ領域に設定されました。



Morrisワームの実行可能なロードは簡単でした。スタックレイアウトがわずかに異なる場合に備えて、400個のNOP命令で始まり、次に短いコードが続きます。このコードは、シェル/ bin / shと呼ばれます。これは典型的な攻撃負荷です。 fingerdプログラムはルートの下で起動したため、攻撃中にシェルを起動すると、シェルもルートの下で起動しました。 Fingerdはネットワークに接続され、「キーボード入力」を受け入れ、同様に出力をネットワークに送り返しました。これらの両方は、エクスプロイトによって引き起こされたシェルを継承しました。これは、ルートシェルが攻撃者がリモートで利用できるようになったことを意味します。



gets（）を使用することは簡単に回避できるという事実にもかかわらず-Morrisワームの配布中であっても、gets（）を使用しないフィンガードバージョンは利用できませんでした-他のCコンポーネントは無視するのがより難しく、エラーも少なくありません。問題の典型的な原因は、Cでの文字列処理です。前述の動作（ゼロバイトで停止）は、Cの文字列の動作に戻ります。Cでは、文字列はゼロバイトで終了する文字シーケンスです。 Cには、文字列を操作するための一連の関数があります。おそらく最良の例はstrcpy（）、ある場所から別の場所に文字列をコピーすること、そしてstrcat（）でしょう、ソース行を宛先の後に挿入します。これらの関数には、宛先バッファサイズパラメータはありません。両方がNULLに遭遇するまでソースから無限に楽しく読み、宛先バッファを満たし、それを気楽にいっぱいにします。



Cの文字列関数にバッファサイズパラメータがある場合でも、エラーとオーバーフローを引き起こす方法でこれを実装します。 Cには、strncat（）およびstrncpy（）と呼ばれる、いくつかの関連する関数strcat（）およびstrcpy （）があります。手紙nこれらの関数の名前の意味は、何らかの方法でパラメーターとしてサイズを取ることです。ただし、nは、多くの素朴なプログラマーの考え方は異なりますが、書き込まれるバッファーのサイズではなく、ソースから読み取る文字数です。ソースの文字がなくなった場合（つまり、ゼロバイトに達した場合）、strncpy（）およびstrncat（）は残りをゼロで埋めます。これらの関数には、宛先の実際のサイズをチェックするものはありません。



gets（）とは異なり、これらの関数は安全な方法で使用できますが、これは簡単ではありません。 C ++およびObjective-Cには、これらのC関数のより優れた代替手段があり、文字列の操作が簡単かつ安全になりますが、下位互換性のためにC関数もサポートされています。



さらに、これらはC言語の基本的な欠陥を保持します。バッファはサイズを知らず、言語はバッファで実行される読み取りと書き込みをチェックせず、オーバーフローを許可します。この動作により、OpenSSLの最近のHeartbleedバグが発生しました。これはオーバーフローではなく、OpenSSLのCコードがバッファに含まれている以上の読み取りを試みて、情報をマージしようとしたときの再読み取りです。

穴パッチ

もちろん、人類は、読み取りバッファと書き込みバッファをチェックする多くの言語を開発しており、オーバーフローを防ぎます。 MozillaがサポートするRustなどのコンパイルされた言語、Javaや.NETなどのセキュアランタイム、Python、JavaScript、Lua、Perlなどのほとんどすべてのスクリプト言語はこの問題の影響を受けません（ただし、.NET開発者は明示的に保護を無効にして公開できます）自分はバグのようですが、それは個人的な選択です）。



バッファオーバーフローが引き続きセキュリティ環境の一部であるという事実は、Cの人気を示唆しています。これの理由の1つは、もちろん、大量のレガシーコードです。世界には、すべての主要なオペレーティングシステムのカーネルやOpenSSLなどの一般的なライブラリなど、膨大な量のCコードがあります。開発者がC＃のような安全な言語を使用したい場合でも、Cで記述されたサードパーティライブラリに依存している場合があります。



Cを継続して使用するもう1つの理由はパフォーマンスですが、このアプローチの意味は必ずしも明確ではありません。コンパイルされたCおよびC ++は通常、高速な実行可能コードを生成することは事実であり、場合によってはこれは非常に重要です。しかし、私たちの多くにとって、プロセッサはほとんどの時間アイドル状態です。たとえば、ブラウザのパフォーマンスの10％を犠牲にすることができても、同時にバッファオーバーフローの不可能性の鉄の保証を取得できる場合、およびその他の一般的なホールは、これが悪い交換ではないと判断する可能性があります。そのようなブラウザを急いで作成する人は誰もいません。



すべてにもかかわらず、Cの仲間はどこにも行かない。バッファオーバーフローも同様です。



この種のエラーを防ぐために、いくつかの手順が取られています。開発中に、特別なツールを使用してソースコードと実行中のプログラムを分析し、これらのバグがリリースに忍び寄る前に危険な構造またはオーバーフローエラーを検出することができます。AddressSanitizerなどの新しいツールとValgrindのような古いツールは、このような機能を提供します。



ただし、これらのツールは両方とも積極的な開発者の介入を必要とします。つまり、すべてのプログラムがそれらを使用するわけではありません。バッファオーバーフローが発生した場合のバッファオーバーフローの危険性を減らすことを目的としたシステム保護は、より多くの異なるソフトウェアを保護できます。これを理解して、オペレーティングシステムとコンパイラの開発者は、これらの脆弱性の悪用を複雑にする多くのメカニズムを実装しています。



これらのシステムの一部は、特定の攻撃を複雑にすることを目的としています。 Linux用のパッチセットの1つは、アドレスに少なくとも1つのゼロバイトが含まれるように、すべてのシステムライブラリが下位アドレスにロードされるようにします。これにより、Cで文字列処理を利用するオーバーフローでの使用が非常に複雑になります。



他の救済策はより一般的です。多くのコンパイラには、ある種のスタック保護があります。実行段階で決定された値は、カナリアと呼ばれ、戻りアドレスの隣のスタックの最後に書き込まれます。各関数の最後で、この値はreturnステートメントを実行する前にチェックされます。カナリアの値が変更された場合（オーバーフロー中の上書きにより）、プログラムは続行せずに直ちにクラッシュします。



おそらく最も重要なセキュリティ機能は、W ^ X（「排他的書き込みまたは実行」書き込み）、DEP（「データ実行防止」）、NX（「Xecuteなし」）、XD（「eXecute無効化」）、EVP （AMD固有の用語である「強化されたウイルス保護」）、XN（「eXecute Never」）、おそらくその他。原則はシンプルです。これらのシステムは、メモリをライトダウン（バッファーに適した）と実行可能（ライブラリおよびプログラムコード）、ただし両方同時にではないため、攻撃者がバッファをオーバーフローさせてリターンアドレスを制御できる場合でも、プロセッサはshellkを実行しませんod。



あなたがそれを呼ぶものは何でも、これは投資を必要としないので、これも重要なメカニズムです。このアプローチは、仮想メモリのハードウェアサポートメカニズムの一部であるため、プロセッサに組み込まれた保護手段を使用します。



前述のように、仮想メモリモードでは、各プロセスは独自のプライベートメモリアドレスのセットを受け取ります。オペレーティングシステムとプロセッサは、仮想アドレスと他の何かの比率を共同でサポートします。仮想アドレスが物理メモリにマップされることもあれば、ディスク上のファイルの一部にマップされることもあれば、どこにもないこともあります。単に割り当てられていないからです。このマッピングはきめ細かで、通常、ページと呼ばれる4096バイトの部分で発生します。



表示に使用されるデータ構造には、各ページの場所（物理メモリ、ディスク、どこにもありません）だけでなく、また、通常、ページのセキュリティを定義する3つのビット（ページが読み取り可能、書き込み可能、​​実行済みかどうか）が含まれます。このような保護により、スタックなどのデータに使用されるプロセスメモリ領域は、読み取りおよび書き込み用にマークできますが、実行できません。



NXの興味深い点の1つは、オペレーティングシステムを保護をサポートするものに更新するだけで、既存のプログラムに遡及的に適用できることです。プログラムで問題が発生する場合があります。 Javaおよび.NETで使用されるJIT（Just-in-time）コンパイラは、実行時にメモリに実行可能コードを生成するため、書き込みおよび実行可能なメモリが必要です（ただし、これらのプロパティの同時性は必要ありません）。 NXがまだない場合は、読み取り可能な任意のメモリからコードを実行できるため、このようなJITコンパイラの特別な読み取り/書き込みバッファに問題はありませんでした。 NXの登場により、メモリ保護が読み取り/書き込みから読み取り/実行に変更されたことを確認する必要があります。



NXのようなものの必要性は、特にMicrosoftにとって明らかでした。 2000年代初頭、2つのワームがコードセキュリティに深刻な問題を抱えていることを明らかにしました。2001年7月にMicrosoft IIS WebサーバーでWindows 2000を実行している少なくとも359,000システムに感染したCode Redと、75,000以上のシステムに感染したSQL Slammer 2003年1月にMicrosoft SQL Serverを使用しました。これらのケースは評判をよく打ちました。



両方のワームはスタックバッファオーバーフローを悪用し、Morrisワームよりもそれぞれ13年後と15年後に出現したにもかかわらず、操作方法がほぼ同じだったことは驚くべきことです。エクスプロイトの負荷はスタックベースのバッファに置かれ、リターンアドレスを書き直しました（わずかな違いは、両方のワームがスプリングボード方式を使用したことです。直接スタックアドレスの代わりに、スタックに制御を戻す命令のアドレスがリターンアドレスに書き込まれました）。



当然、これらのワームは他の分野でより高度でした。 Code Redのロードは、単なる自己複製ではありませんでした。彼女はWebページを改ざんし、DoS攻撃を試みました。 SQL Slammerは、感染したマシンに痕跡を残さずに、ネットワーク上の感染と配布の新しいターゲットを検索するために必要なすべてを実行しました。マシンを再起動します-そこにはありません。どちらのワームもインターネットで動作しました。これは、モリスワームが広がったワームよりも何倍も大きかったため、感染数ははるかに多くなりました。



ただし、主な問題-簡単に悪用されるスタックバッファオーバーフロー-は同じままです。これらのワームは見出しに登場し、多くの種類のWindowsをインターネット上のサーバーとして使用する可能性を疑っていました。マイクロソフトの答えは、セキュリティについて真剣に考え始めることでした。 Windows XP Service Pack 2は最初のセキュリティインストールでした。ソフトウェアファイアウォールの追加、ツールバーとプラグインのサイレントインストールを妨げるInternet Explorerの変更、NXのサポートなど、いくつかのソフトウェアの変更が行われました。



NX対応ハードウェアは、2004年頃にIntelがPrescott Pentium 4を導入したときに登場し始め、Windows XP SP2以降オペレーティングシステムのサポートが一般的になりました。Windows 8では、NXの実行方法がわからないプロセッサのサポートを拒否して、この瞬間をさらに強制することにしました。

NXの後の出来事

NXサポートの普及にもかかわらず、バッファオーバーフローは依然として緊急の情報セキュリティ問題です。その理由は、NXをバイパスする多くの方法の開発です。



それらの最初のものは、上記のスプリングボードに類似しており、別のライブラリまたは実行可能ファイルにある命令を介してスタックバッファ内のシェルコードに制御を転送します。攻撃者は、制御をスタックに直接転送する実行可能コードのフラグメントを探す代わりに、何か有用なことを行うフラグメントを見つけます。



おそらく、この役割の最適な候補は、Unix関数システム（）です。。 1つのパラメーターが必要です。実行するコマンドを表す文字列のアドレスです。通常、このパラメーターはスタックを介して渡されます。攻撃者は必要なコマンドを作成し、それをオーバーフローしたバッファーに入れることができます。（従来）メモリ内のオブジェクトの場所は変わらないため、この行のアドレスがわかっており、攻撃中にスタックにプッシュできます。この場合、書き換えられた戻りアドレスは、バッファ内のアドレスを示していません。system（）関数を指します。オーバーフローが発生しやすい関数が終了すると、呼び出し元の関数に戻る代わりにsystem（）が起動し、攻撃者によって指定されたコマンドが実行されます。



これは、NXを回避する方法です。機能システム（）システムライブラリの一部であることは既に実行可能です。このエクスプロイトでは、スタックからコードを実行する必要はありません。そこからコマンドを読むだけです。この手法は「return-to-libc」（libcに戻り、システム（）を含む多くの主要な機能を含むUnixライブラリであり、通常すべてのUnixプロセスにロードされるため、このような使用に適したターゲットになります） 1997年、ロシアの情報セキュリティの専門家であるSolar Designer。



この手法は便利ですが、制限があります。多くの場合、関数はスタックからではなく、レジスタから引数を受け取ります。実行のためにコマンドを転送するのは便利ですが、多くの場合、これらの愚かなゼロが含まれており、これは大きな障害です。さらに、この方法で一連の異なる呼び出しを構成するのは簡単ではありません。1つではなく複数のリターンアドレスを登録することは可能ですが、リターン値またはその他のものを使用して引数の順序を変更する方法はありません。

バッファをシェルコードで埋める代わりに、一連の戻りアドレスとデータで埋めます。これらの戻りアドレスは、犠牲プログラムとそのライブラリ内の実行可能コードの既存のフラグメントに制御を移します。コードの各部分は、操作を実行して戻りを実行し、次の戻りアドレスに制御を渡します。

長年にわたり、これらの制限を回避するために、libcへの復帰が一般化されてきました。 2001年の終わりに、このメソッドのいくつかの拡張オプションが文書化されました。複数呼び出しの可能性とゼロバイト問題の解決策です。 これらの問題のほとんどを解決したより複雑な方法は、 2007年に正式に記述されました：リターン指向プログラミング（ROP、リターン指向プログラミング）。



return-to-libcおよびspringboardと同じ原理を使用しますが、より一般化されています。 スプリングボードが実行をバッファ内のシェルコードに転送するために単一のコードを使用する場合、ROPは元の出版物で「ガジェット」と呼ばれる多くのコードを使用します。 各ガジェットは特定のパターンに従います。特定の操作（レジスタへの値の書き込み、メモリへの書き込み、レジスタの追加など）を実行した後、リターンコマンドを実行します。 x86をスプリングボードに適したものにするまさにその特性がここで機能します。 プロセスメモリに読み込まれたシステムライブラリには、「アクションとリターン」として解釈できる数百のシーケンスが含まれています。これは、ROP攻撃に使用できることを意味します。



ガジェットを単一のユニットに結合するには、バッファオーバーフロー中にスタックに書き込まれた長い一連のリターンアドレス（および有用で必要なデータ）が使用されます。 戻り命令はガジェットからガジェットにジャンプしますが、プロセッサは関数を呼び出すことはめったにない（またはまったくしない） が、関数からは戻ります。 興味深いことに、少なくともx86では、有用なガジェットの数と種類が多く、攻撃者は文字通り何でもできます。 特別な方法で使用されるこのx86のサブセットは、多くの場合チューリング完全です（ただし、機能の全範囲は、プログラムによってロードされるライブラリ、したがって利用可能なガジェットのリストに依存します）。



return-to-libcと同様に、実際に実行可能なコードはすべてシステムライブラリから取得されるため、NXのような保護は役に立ちません。 このアプローチの優れた柔軟性は、エクスプロイトが、例えば、レジ​​スターを介して引数を取る関数を呼び出す、他の関数の戻り値を使用するなど、libcに戻るシーケンスで整理するのが困難なことを行えることを意味します。



ROP攻撃の負荷は異なります。 これは、シェル（シェルへのアクセス）を取得する単純なコードである場合があります。 もう1つの一般的なオプションは、ROPを使用してシステム関数を呼び出し、メモリページのNXパラメーターを変更して、書き込み済みから実行可能に変更することです。 これにより、攻撃者は通常の非ROPロードを使用できます。

ランダム化

NXのこの弱点は古くから知られており、このタイプのパターンを悪用しています。攻撃者はメモリ内のスタックおよびシステムライブラリのアドレスを事前に知っています。 すべてはこの知識に基づいているため、明らかな解決策は攻撃者からこの知識を奪うことです。 これはまさにASLRが行うことです（アドレス空間レイアウトのランダム化）。スタックの位置と、ライブラリおよび実行可能コードのメモリ内の位置をランダム化します。 通常、プログラムが起動、再起動、またはそれらの組み合わせのたびに変更されます。



非常に予想外なことに、攻撃者はROPに必要な命令フラグメントがどこにあるか、または少なくともオーバーフロースタックがどこにあるかを知らないため、この状況は操作を著しく複雑にします。



ASLRは主にNXに付属しており、libcまたはROPに戻るなどの大きなホールを閉じます。 残念ながら、NXよりも透過性がわずかに劣ります。 JITコンパイラーや他の多くの特定のケースとは別に、NXは既存のプログラムに安全に統合できます。 ASLRにはさらに問題があります。それにより、プログラムやライブラリは、ロード先のアドレスの値に依存することができなくなります。



たとえば、Windowsでは、これはDLLにとって大きな問題ではありません。 Windowsでは、DLLは常に異なるアドレスへの読み込みをサポートしていましたが、EXEではこれが問題になる可能性があります。 ASLR以前は、EXEは常に0x0040000でロードされていたため、この事実に依存していました。 ASLRでは、これは当てはまりません。 潜在的な問題を防ぐために、Windowsでは、デフォルトでASLRサポートを明示的に指定するプログラムが必要です。 ただし、セキュリティ思想家は、WindowsにすべてのプログラムとライブラリのASLRを有効にすることにより、このデフォルトの動作を変更できます。 これが問題を引き起こすことはほとんどありません。



x86上のLinuxでは、このプラットフォームでASLRを実装するアプローチにより、パフォーマンスが最大26％低下するため、状況はおそらく悪化します。 さらに、このアプローチでは 、ASLRをサポートするプログラムとライブラリをコンパイルする必要があります。 Windowsのように、管理者がASLRを強制する方法はありません（x64では、パフォーマンスの低下はまったくなくなりませんが、大幅に削減されます）



ASLRがアクティブな場合、単純なハッキングに対する強力な保護を提供します。 しかし、彼は完璧ではありません。 たとえば、制限の1つは、取得できるランダム性の程度です。これは、32ビットシステムで特に顕著です。 アドレス空間には40億の異なるアドレスがありますが、それらのすべてがライブラリのロードやスタックに使用できるわけではありません。



これには多くの制限があります。 それらのいくつかは目的の幅広さです。 一般に、オペレーティングシステムは、プロセスのアドレス空間の一方の端でライブラリを互いに近くにロードすることを選択して、アプリケーションでできるだけ多くの連続した空間を利用できるようにします。 256 MBのメモリごとに1つのライブラリを取得するのは望ましくありません。メモリの最大単位割り当ては256 MB未満になるため、アプリケーションが大量のデータを処理する能力が制限されるためです。



通常、実行可能ファイルとライブラリは、少なくともページの境界で始まるようにロードする必要があります。 通常、これは、4096で割り切れるアドレスにロードする必要があることを意味します。異なるプラットフォームには、同様のスタック制限があります。 たとえば、Linuxは16で割り切れるアドレスでスタックを開始します。メモリ制限のあるシステムでは、すべてを配置できるようにするために、ランダム性をさらに制限しなければならない場合があります。



結果は異なりますが、攻撃者がヒットする可能性が高い場合に、正しいアドレスを推測できる場合があります。 状況によっては、低い確率（たとえば256の1つ）でも十分な場合があります。 クラッシュしたプロセスを自動的に再起動するWebサーバーを攻撃する場合、256の攻撃のうち255がプロセスをクラッシュすることは問題ではありません。 再起動され、再試行できます。



しかし、64ビットシステムでは、アドレス空間が非常に大きいため、このようなアプローチは役に立ちません。 攻撃者は、100万回に1回、または10億回に1回しかチャンスを持たない可能性があり、これは重要ではないほど十分に小さいものです。



たとえば、ブラウザを攻撃するのは推測や落下は良い戦略ではありません。 攻撃者にチャンスを与えるためだけに、ユーザーが連続して256回ブラウザを再起動することはありません。 その結果、アクティブなNXおよびASLRを備えたシステムでのこのような脆弱性の悪用は、支援なしでは実行できません。



このような支援にはいくつかの種類があります。 ブラウザでJavaScriptまたはFlashを使用すると（どちらにも実行可能コードを生成するJITコンパイラが含まれています）、きちんと設計された実行可能コードでメモリを埋めることができます。 これにより、大きな着陸帯のようなものが作成されます。これは、「ヒープスプレー」（「ヒープスプレー」）と呼ばれる技術です。 別のアプローチとして、ライブラリのアドレスを開いたり、メモリ内にスタックしたりするための2次的なバグを見つけ、攻撃者にROPの特定のリターンアドレスセットを作成するのに十分な情報を与えることができます。



3番目のアプローチはブラウザでも一般的でした。ASLRの方法がわからないライブラリを使用します。 Adobe PDFプラグインやMicrosoft Officeなどの古いバージョンはASLRをサポートしておらず、WindowsはデフォルトでASLRを強制しません。 攻撃者がそのようなライブラリのロードを引き起こす可能性がある場合（たとえば、非表示のブラウザフレームにPDFをダウンロードすることにより）、ASLRを心配する必要はなくなりますが、ROP目的でこのライブラリを使用します。

終わりのない戦争

脆弱性を悪用する人々と防御する人々の間には、絶え間ない軍拡競争があります。 ASLRやNXなどの強力な防御システムは水準を引き上げ、欠陥の使用を困難にします。それらのおかげで、単純なバッファーオーバーフローの時代を残しましたが、賢明な攻撃者は穴の組み合わせを見つけて、これらの保護対策を回避できます。



エスカレーションは続きます。 Microsoft EMET （Enhanced Mitigation Experience Toolkit）には、ヒープスプレーまたはROPエクスプロイトの特定の重要な機能の呼び出しを検出できる一連の半実験的防御が含まれています。 しかし、継続的なデジタル戦争では、これらのトリックのいくつかでさえすでに敗北しています。 これにより、それらが役に立たなくなることはありません-脆弱性を悪用する複雑さ（およびそのための価格）は、各対策が適用されるたびに増加します-しかし、これは絶え間ない警戒の必要性を思い出させます。