スタックバッファオーバーフロー

ソフトウェアでは、スタック バッファ オーバーフローまたはスタック バッファ オーバーランは、プログラムがプログラムの呼び出しスタック上のメモリアドレスに、通常は固定長バッファである意図されたデータ構造の外側に書き込むときに発生します。^{[1] [2]} スタック バッファ オーバーフローのバグは、プログラムがスタック上にあるバッファに、そのバッファに実際に割り当てられている量よりも多くのデータを書き込むときに発生します。これにより、ほとんどの場合、スタック上の隣接データが破損し、オーバーフローが誤ってトリガーされた場合は、プログラムがクラッシュしたり、正しく動作しなかったりすることがよくあります。スタック バッファ オーバーフローは、バッファ オーバーフロー(またはバッファ オーバーラン) と呼ばれる、より一般的なプログラミングの不具合の一種です。^[1]スタックにはすべてのアクティブな関数呼び出しの戻りアドレスが含まれているため、スタック上のバ​​ッファがいっぱいになると、ヒープ上のバッファがいっぱいになるよりもプログラムの実行が失敗する可能性が高くなります。

スタック バッファ オーバーフローは、スタック スマッシングと呼ばれる攻撃の一環として意図的に引き起こされることがあります。影響を受けるプログラムが特別な権限で実行されている場合、または信頼できないネットワーク ホスト ( Web サーバーなど) からデータを受け入れる場合、このバグは潜在的なセキュリティ脆弱性となります。スタック バッファが信頼できないユーザーから提供されたデータでいっぱいになると、そのユーザーはスタックを破壊して実行中のプログラムに実行可能コードを挿入し、プロセスを制御できるようになります。これは、攻撃者がコンピューターに不正アクセスするための最も古く、最も信頼性の高い方法の 1 つです。^{[3] [4] [5]}

スタックベースのバッファオーバーフローを悪用する標準的な方法は、関数の戻りアドレスを攻撃者が制御するデータ（通常はスタック自体にある）へのポインタで上書きすることです。 ^{[3] [6]}strcpy()これは次の例で 説明されています。

#include <文字列.h> 

void foo ( char * bar ) { char c [ 12 ] ;  

    

   strcpy ( c , bar ); // 境界チェックなし}   


int main ( int argc , char ** argv ) { foo ( argv [ 1 ] ); 0を返す; }    

   
    

このコードは、コマンドラインから引数を受け取り、それをローカル スタック変数にコピーしますc。これは、12 文字未満のコマンドライン引数では正常に機能します (下の図 B を参照)。11 文字を超える引数は、スタックの破損につながります。(安全な最大文字数は、ここではバッファ サイズより 1 少ない数です。これは、C プログラミング言語では、文字列がヌル バイト文字で終了するためです。したがって、12 文字の入力を格納するには、入力の後にセンチネル ゼロ バイトが続く 13 バイトが必要です。ゼロ バイトは、バッファの末尾から 1 バイト先のメモリ位置を上書きすることになります。)

プログラムはfoo()さまざまな入力でスタックされます:

上の図 C では、11 バイトを超える引数がコマンド ラインで提供されると、foo()ローカル スタック データ、保存されたフレーム ポインタ、そして最も重要な戻りアドレスが上書きされます。 がfoo()戻ると、戻りアドレスがスタックからポップされ、そのアドレスにジャンプします (つまり、そのアドレスから命令の実行を開始します)。このように、攻撃者は戻りアドレスをスタック バッファへのポインタで上書きしchar c[12]、スタック バッファには攻撃者が提供したデータが含まれるようになります。実際のスタック バッファ オーバーフロー エクスプロイトでは、"A" の文字列は、プラットフォームと目的の機能に適したシェルコードになります。このプログラムに特別な権限がある場合 (たとえば、スーパーユーザーとして実行するようにSUIDビットが設定されている)、攻撃者はこの脆弱性を利用して、影響を受けるマシンでスーパーユーザー権限を取得できます。^[3]

攻撃者は、バグを悪用するために内部変数の値を変更することもできます。この例では、

#include <文字列.h> #include <stdio.h> 
 

void foo ( char * bar ) { float My_Float = 10.5 ; // アドレス = 0x0023FF4C char c [ 28 ]; // アドレス = 0x0023FF30  

       
                

   // 10.500000 を出力します
printf ( "My Float value = %f \n " , My_Float );    

    /* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       メモリマップ: 
       @ : c 割り当てられたメモリ
       # : My_Float 割り当てられたメモリ

           *c *My_Float 
       0x0023FF30 0x0023FF4C 
           | | 
           @@@@@@@@@@@@@@@@@@@@@@@@@@@@##### 
      foo("文字列が長すぎます!!!!! XXXXX");

   memcpy は My_Float 値に 0x1010C042 (リトルエンディアン) を設定します。
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/

   memcpy ( c , bar , strlen ( bar )); // 境界チェックなし...    

   // 96.031372 を出力します
printf ( "My Float value = %f \n " , My_Float ); }    


int main ( int argc , char ** argv ) { foo ( "文字列が長すぎます!!!!! \x10\x10\xc0\x42 " ); return 0 ; }    

   
    

スタックに格納されたアドレスを変更するために使用される方法には、通常、直接的と間接的の 2 つがあります。攻撃者は、直接攻撃を減らすために作られた保護手段を回避するために、依存関係の少ない間接的な攻撃を開発し始めました。^[7]

多くのプラットフォームでは、コール スタックの実装に微妙な違いがあり、スタック バッファ オーバーフロー攻撃の仕組みに影響する可能性があります。一部のマシン アーキテクチャでは、コール スタックの最上位の戻りアドレスをレジスタに格納します。つまり、上書きされた戻りアドレスは、後でコール スタックがアンワインドされるまで使用されません。攻撃手法の選択に影響する可能性のあるマシン固有の詳細のもう 1 つの例は、ほとんどのRISCスタイルのマシン アーキテクチャでは、メモリへの非整列アクセスが許可されないという事実です。^[8]マシン オペコードの長さが固定されていることと相まって、このマシンの制限により、スタックにジャンプする手法を実装することがほぼ不可能になります (プログラムに、スタック レジスタに明示的にジャンプするありそうもないコードが実際に含まれている場合を除く)。^{[9] [10]}

スタック バッファ オーバーフローの話題では、スタックが逆方向に拡大するアーキテクチャがよく議論されるが、めったに見られないアーキテクチャです。このアーキテクチャの変更は、スタック バッファ オーバーフローの問題の解決策として頻繁に提案されています。これは、同じスタック フレーム内で発生するスタック バッファのオーバーフローは、戻りポインタを上書きできないためです。ただし、以前のスタック フレームのバッファで発生するオーバーフローは、戻りポインタを上書きし、バグを悪用する悪意のある攻撃を可能にします。^[11]たとえば、上記の例では、オーバーフローfooは実際には のスタック フレーム内で発生するため、 の戻りポインタは上書きされませんmemcpy。ただし、 の呼び出し中にオーバーフローするバッファはmemcpy以前のスタック フレームに存在するため、 の戻りポインタは、memcpyバッファよりも数値的に高いメモリ アドレスを持ちます。つまり、 の戻りポインタがfoo上書きされるのではなく、 の戻りポインタがmemcpy上書きされることになります。せいぜい、スタックを逆方向に拡大すると、スタック バッファ オーバーフローの悪用方法の詳細がいくらか変更されますが、悪用可能なバグの数が大幅に減少するわけではありません。^[要出典]

長年にわたり、悪意のあるスタック バッファ オーバーフローの悪用を阻止するために、さまざまな制御フロー整合性スキームが開発されてきました。これらは通常、次の 3 つのカテゴリに分類できます。

• スタック バッファ オーバーフローが発生したことを検出し、命令ポインタが悪意のあるコードにリダイレクトされるのを防ぎます。
• スタック バッファ オーバーフローを直接検出せずに、スタックからの悪意のあるコードの実行を防止します。
• 実行可能コードの検索が信頼できなくなるようにメモリ空間をランダム化します。

スタック カナリアは炭鉱のカナリアに例えられ、悪意のあるコードが実行される前にスタック バッファ オーバーフローを検出するために使用されます。この方法は、プログラムの開始時にランダムに選択された値の小さな整数を、スタック リターン ポインタの直前のメモリに配置することによって機能します。ほとんどのバッファ オーバーフローは、メモリを下位のメモリ アドレスから上位のメモリ アドレスに上書きするため、リターン ポインタを上書きして (したがってプロセスを制御するには)、カナリア値も上書きする必要があります。この値は、ルーチンがスタック上のリターン ポインタを使用する前に変更されていないことを確認するためにチェックされます。^[2]この手法では、スタック バッファ オーバーフローを悪用することが非常に困難になります。これは、スタック上の他の重要な変数を破壊するなどの非伝統的な手段によって攻撃者が命令ポインタの制御を取得することを余儀なくされるためです。^[2]

スタック バッファ オーバーフローの悪用を防ぐもう 1 つの方法は、スタック メモリ領域に、スタックからの実行を許可しないメモリ ポリシーを適用することです ( W^X、「Write XOR Execute」)。つまり、スタックからシェルコードを実行するには、攻撃者はメモリからの実行保護を無効にする方法を見つけるか、シェルコード ペイロードをメモリの保護されていない領域に配置する方法を見つける必要があります。この方法は、ほとんどのデスクトップ プロセッサで no-execute フラグのハードウェア サポートが利用できるようになったため、ますます普及しつつあります。

この方法は標準的なスタックスマッシング攻撃を阻止しますが、スタックオーバーフローは他の方法でも悪用される可能性があります。まず、ヒープのような保護されていないメモリ領域にシェルコードを保存する方法は一般的であるため、悪用方法を変更する必要はほとんどありません。^[12]

もう一つの攻撃は、シェルコード作成のためのいわゆるreturn to libcメソッドです。この攻撃では、悪意のあるペイロードがシェルコードではなく適切なコールスタックをスタックにロードし、実行が一連の標準ライブラリ呼び出しにベクトル化されるようにします。通常、その結果、メモリ実行保護が無効になり、シェルコードが通常どおり実行されるようになります。^[13]この方法が機能するのは、実行が実際にはスタック自体にベクトル化されないためです。

return-to-libc の変種として、リターン指向プログラミング(ROP) があります。これは、一連のリターン アドレスを設定し、各リターン アドレスで、既存のプログラム コードまたはシステム ライブラリ内の厳選されたマシン命令の小さなシーケンスを実行し、そのシーケンスはリターンで終わります。これらのいわゆるガジェットは、それぞれ、リターンする前に簡単なレジスタ操作または同様の実行を実行し、それらを連結することで攻撃者の目的を達成します。リターン命令とよく似た動作をする命令または命令のグループを利用することで、「リターンレス」のリターン指向プログラミングを使用することさえ可能です。^[14]

コードとデータを分離する代わりに、実行プログラムのメモリ空間にランダム化を導入するという軽減手法もあります。攻撃者は、使用可能な実行可能コードがどこにあるかを判断する必要があるため、実行可能ペイロード (実行可能スタック付き) を提供するか、ret2libc やリターン指向プログラミング (ROP) などのコード再利用を使用してペイロードを構築します。メモリ レイアウトをランダム化すると、概念的には、攻撃者がコードの場所を知ることができなくなります。ただし、実装では通常、すべてがランダム化されるわけではありません。通常、実行可能ファイル自体は固定アドレスにロードされるため、ASLR (アドレス空間レイアウト ランダム化) が非実行可能スタックと組み合わされても、攻撃者はこの固定メモリ領域を使用できます。したがって、すべてのプログラムは、このメモリ領域もランダム化されるようにPIE (位置独立実行可能ファイル) でコンパイルする必要があります。ランダム化のエントロピーは実装ごとに異なり、エントロピーが十分に低いと、ランダム化されたメモリ空間をブルート フォース攻撃する上で問題になることがあります。

これまでの緩和策により、悪用の手順はより困難になりました。しかし、何らかの脆弱性が存在したり、いくつかの条件が満たされたりすると、スタックバッファオーバーフローを悪用することは依然として可能です。^[15]

攻撃者はフォーマット文字列の脆弱性を悪用して、脆弱なプログラム内のメモリ位置を明らかにすることができます。 ^[16]

データ実行防止機能が有効になっていてスタックへの実行アクセスを禁止している場合でも、攻撃者は上書きされた戻りアドレス（命令ポインタ）を使用して、コードセグメント（ Linuxでは.text）またはプログラムの他のすべての実行可能セクション内のデータを指すことができます。目的は、既存のコードを再利用することです。^[17]

プログラムの戻り命令（x86ではret）の少し前に戻りポインタを上書きする。新しい戻りポインタと戻り命令の間の命令が実行され、戻り命令はエクスプロイトによって制御されるペイロードに戻る。^{[17] [説明が必要]}

ジャンプ指向プログラミングは、ret命令の代わりにジャンプ命令を使用してコードを再利用する手法です。^[18]

64ビットシステムでのASLR実現の限界は、メモリ漏洩や情報漏洩攻撃に対して脆弱であることです。攻撃者は情報漏洩攻撃を使用して単一の関数アドレスを明らかにすることでROPを起動できます。次のセクションでは、ASLR保護を破るための同様の既存の戦略について説明します。^[19]

• 1988年のモリスワームは、Unix フィンガーサーバーのスタックバッファオーバーフローを悪用して拡散した。[1]
• 2003年のSlammerワームは、 MicrosoftのSQLサーバーのスタックバッファオーバーフローを悪用して拡散しました。[2]
• 2003 年のBlasterワームは、Microsoft DCOMサービスのスタック バッファ オーバーフローを悪用して拡散しました。
• 2004年のWittyワームは、インターネットセキュリティシステムのBlackICEデスクトップエージェントのスタックバッファオーバーフローを悪用して拡散しました。[3]
• Wiiでは、改造されていないシステム上で任意のコードを実行できる例がいくつかある。 『ゼルダの伝説 トワイライトプリンセス^{』の主人公の馬に長い名前を付ける「トワイライトハック」 [20]}や、『大乱闘スマッシュブラザーズX』の「スマッシュスタック」では、 SD カードを使用して特別に用意されたファイルをゲーム内のレベルエディターにロードする。どちらも任意のコードを実行するために使用できるが、後者は、修正を適用した状態で単にBrawl自体をリロードするためによく使用される。^[21]

• サイバー犯罪
• エグゼクティブシールド
• ヒープオーバーフロー
• 整数オーバーフロー
• NX ビット– メモリ領域の実行禁止ビット
• セキュリティ強化Linux
• スタックオーバーフロー– スタック自体がオーバーフローした場合
• 保管違反