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

バッファ オーバーフロー保護は、スタックに割り当てられた変数のバッファ オーバーフローを検出し、プログラムの不正動作や重大なセキュリティ脆弱性の発生を防ぐことで、実行可能プログラムのセキュリティを強化するためにソフトウェア開発中に使用されるさまざまな手法の 1 つです。スタック バッファ オーバーフローは、プログラムが、通常は固定長バッファである意図されたデータ構造の外側にあるプログラムの呼び出しスタックのメモリ アドレスに書き込むときに発生します。スタック バッファ オーバーフロー バグは、プログラムがスタックにあるバッファに、そのバッファに実際に割り当てられている量よりも多くのデータを書き込むときに発生します。これにより、スタック上の隣接データが破損することがほとんどで、プログラムのクラッシュ、不正な操作、またはセキュリティの問題につながる可能性があります。

通常、バッファ オーバーフロー保護は、スタックに割り当てられたデータの構成を変更して、スタック バッファ オーバーフローによって破壊されたときに、メモリ内のその前のバッファがオーバーフローしたことを示すカナリア値を含めます。カナリア値を検証することで、影響を受けるプログラムの実行を終了し、プログラムの誤動作や攻撃者による制御の取得を防止できます。その他のバッファ オーバーフロー保護技術には、割り当てられた各メモリ ブロックへのアクセスをチェックして実際に割り当てられた領域を超えないようにする境界チェックや、データを格納するために割り当てられたメモリに実行可能コードが含まれないようにする タグ付けなどがあります。

スタックにはすべてのアクティブな関数呼び出しの戻りアドレスが含まれているため、スタックに割り当てられたバッファがオーバーフィルされると、ヒープ上のバッファがオーバーフィルされるよりもプログラムの実行に影響を及ぼす可能性が高くなります。ただし、ヒープベースのオーバーフローに対しても同様の実装固有の保護が存在します。

バッファ オーバーフロー保護の実装には、 GNU コンパイラ コレクション、LLVM、Microsoft Visual Studio、その他のコンパイラ 向けのものなど、いくつかあります。

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

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

通常、バッファ オーバーフロー保護は、関数呼び出しのスタック フレーム内のデータの構成を変更して、「カナリア」値を含めます。この値が破棄されると、メモリ内のその前のバッファがオーバーフローしたことを示します。これにより、一連の攻撃をすべて防止できるという利点があります。一部の研究者によると、^[3]これらの手法によるパフォーマンスへの影響はごくわずかです。

スタックスマッシング保護では、特定の形式の攻撃から保護することはできません。たとえば、ヒープ内のバッファオーバーフローから保護することはできません。構造体内のデータのレイアウトを変更する合理的な方法はありません。構造体は、特に共有ライブラリでは、モジュール間で同じであることが期待されます。バッファ後の構造体内のデータは、カナリアでは保護できません。したがって、プログラマーは変数の編成方法と構造体の使用方法について非常に注意する必要があります。

カナリア、カナリア ワード、またはスタック クッキーは、バッファ オーバーフローを監視するためにスタック上のバ​​ッファと制御データの間に配置される既知の値です。バッファ オーバーフローが発生すると、通常、最初に破損するデータはカナリアであり、カナリア データの検証に失敗するとオーバーフローが警告され、破損したデータを無効にするなどの処理が行われます。カナリア値を センチネル値と混同しないでください。

この用語は、炭鉱でカナリアを使用する歴史的慣習に由来しています。カナリアは炭鉱労働者よりも早く有毒ガスの影響を受け、生物学的警告システムとして機能するからです。カナリアはスタック クッキーとも呼ばれ、値が破損した「壊れたクッキー」のイメージを喚起することを目的としています。

使用されているカナリアには、ターミネーター、ランダム、ランダムXORの 3 種類があります。StackGuard の現在のバージョンではこれら 3 つすべてがサポートされていますが、ProPolice ではターミネーターとランダムのカナリアがサポートされています。

ターミネータ カナリアは、ほとんどのバッファ オーバーフロー攻撃が文字列ターミネータで終了する特定の文字列操作に基づいているという観察を利用します。この観察に対する反応として、カナリアはCR、 LF 、およびFF などのヌルターミネータで構成されます。その結果、攻撃者はカナリアの変更を避けるために、戻りアドレスを書き込む前にヌル文字を書き込む必要があります。これにより、ヌル文字をコピーして戻るその他の方法を使用した攻撃を防止できますが、望ましくない結果、カナリアが既知になります。保護があっても、攻撃者はカナリアを既知の値で上書きし、不一致の値で制御情報を上書きして、特定のプロセッサの呼び出しからの戻り命令の直前に実行されるカナリア チェック コードを渡す可能性があります。 strcpy()

ランダム カナリアは、攻撃者がその値を知ることを防ぐために、通常はエントロピー収集デーモンによってランダムに生成されます。通常、カナリアを読み取って悪用することは論理的に不可能または妥当ではありません。カナリアは、それを知る必要がある人 (この場合はバッファ オーバーフロー保護コード) だけが知っている安全な値です。

通常、ランダムなカナリアはプログラムの初期化時に生成され、グローバル変数に格納されます。この変数は通常、マップされていないページで埋められているため、バグを利用して RAM から読み取るあらゆるトリックを使用してこの変数を読み取ろうとすると、セグメンテーション違反が発生し、プログラムが終了します。攻撃者がカナリアの場所を知っているか、プログラムにスタックから読み取らせることができれば、カナリアを読み取ることは可能です。

ランダム XOR カナリアは、制御データのすべてまたは一部を使用して XOR スクランブルされたランダム カナリアです。このように、カナリアまたは制御データが破壊されると、カナリアの値は間違ったものになります。

ランダム XOR カナリアにはランダム カナリアと同じ脆弱性がありますが、カナリアを取得する「スタックからの読み取り」方法が少し複雑です。攻撃者は、保護を偽装するために必要な元のカナリアを再生成するために、カナリア、アルゴリズム、および制御データを取得する必要があります。

さらに、ランダム XOR カナリアは、構造体のバッファをポインタにオーバーフローさせて、ポインタを制御データの一部を指すように変更する特定の種類の攻撃から保護できます。XOR エンコードのため、制御データまたは戻り値が変更されるとカナリアは誤りになります。ポインタのため、制御データまたは戻り値はカナリアをオーバーフローさせることなく変更できます。

これらのカナリアは、制御データが破壊されたポインタによって変更されるのを防ぎますが、他のデータやポインタ自体は保護しません。関数ポインタは特にオーバーフローして呼び出されたときに シェルコードを実行する可能性があるため、ここでは問題となります。

境界チェックは、割り当てられたメモリブロックごとに実行時の境界情報を追加し、実行時にすべてのポインタをチェックするコンパイラベースの手法です。CおよびC++の場合、境界チェックはポインタ計算時^[4]または逆参照時に実行できます。^{[5] [6] [7]}

このアプローチの実装では、割り当てられたメモリブロックごとに記述する中央リポジトリ^{[4] [5] [6]}または、ポインタと追加データの両方を含み、それらが指す領域を記述するファットポインタ^[7]のいずれかを使用します。

タグ付け^[8]は、コンパイラベースまたはハードウェアベース（タグ付きアーキテクチャが必要）の技術で、メモリ内のデータの型をタグ付けするものであり、主に型チェックに使用されます。メモリの特定の領域を非実行可能としてマークすることで、データを格納するために割り当てられたメモリに実行可能コードが含まれるのを効果的に防ぎます。また、メモリの特定の領域を非割り当てとしてマークすることで、バッファオーバーフローを防ぐことができます。

歴史的に、タグ付けは高級プログラミング言語の実装に使用されてきました。^[9]オペレーティングシステムからの適切なサポートがあれば、タグ付けはバッファオーバーフローの検出にも使用できます。^[10] 一例として、Intel、AMD、ARMプロセッサでサポートされているNXビットハードウェア機能があります。

スタックスマッシング保護は、 1997年にStackGuardによって初めて実装され、1998年のUSENIXセキュリティシンポジウムで公開されました。^{[11] StackGuardは、} GCC 2.7のIntel x86バックエンドへのパッチセットとして導入されました。StackGuardは、1998年から2003年までImmunix Linuxディストリビューション用に保守され、ターミネータ、ランダム、ランダムXORカナリアの実装で拡張されました。GCC 2003サミット議事録では、StackGuardをGCC 3.xに組み込むことが提案されましたが、^[12]これは実現しませんでした。

2001年から2005年にかけて、IBMはProPoliceとして知られるスタック破壊保護のためのGCCパッチを開発しました。^[13]これは、スタックフレーム内のローカルポインタと関数引数の後にバッファを配置することで、StackGuardのアイデアを改良しました。これにより、ポインタの破損を回避し、任意のメモリ位置へのアクセスを防ぐことができました。

しかし、 Red HatのエンジニアはProPoliceに問題があることを突き止め、2005年にスタックスマッシング保護を再実装してGCC 4.1に組み込みました。^{[14] [15]}この作業により-fstack-protector、脆弱な関数のみを保護するフラグと、-fstack-protector-all必要かどうかにかかわらずすべての関数を保護するフラグが導入されました。^[16]

2012年にGoogleのエンジニアは、-fstack-protector-strongセキュリティとパフォーマンスのバランスをより良く取るためにフラグを実装しました。^[17]このフラグは、より多くの種類の脆弱な関数を保護しますが-fstack-protector、すべての関数を保護するわけではないため、よりも優れたパフォーマンスを提供します-fstack-protector-all。GCCバージョン4.9以降で利用できます。^[18]

Fedora のすべてのパッケージは-fstack-protectorFedora Core 5 以降、-fstack-protector-strongFedora 20 以降でコンパイルされています。 ^{[19] [20]} Ubuntuのほとんどのパッケージは6.10 以降でコンパイルされています-fstack-protector。^[21] Arch Linux のすべてのパッケージは-fstack-protector2011 以降でコンパイルされています。^[22] 2014 年 5 月 4 日以降にビルドされたすべての Arch Linux パッケージは を使用します。 ^{[23]スタック保護は}Debianの一部のパッケージでのみ使用され、^[24] FreeBSD 8.0 以降はベースシステムでのみ使用されます。^{[25]スタック保護は}OpenBSD ^[26] Hardened Gentoo ^[27] DragonFly BSDなど、特定のオペレーティングシステムでは標準です。^[要出典]-fstack-protector-strong

StackGuardとProPoliceは、関数ポインタにオーバーフローする自動的に割り当てられた構造体のオーバーフローから保護することはできません。ProPoliceは少なくとも、そのような構造体が関数ポインタの前に割り当てられるように割り当て順序を変更します。ポインタ保護のための別のメカニズムはPointGuard ^[28]で提案されており、Microsoft Windowsで利用可能です。^[29]

Microsoftのコンパイラスイートは、バージョン2003以降、/GSコマンドラインスイッチを通じてバッファオーバーフロー保護を実装しており、バージョン2005以降はデフォルトで有効になっています。 ^[30] /GS-を使用すると、保護が無効になります。

スタックスマッシング保護はコンパイラフラグによって有効にすることができる-qstackprotect。^[31]

-fstack-protectorClangはGCCと同じオプション^[32]と、同様にパフォーマンスへの影響が低い、より強力な「セーフスタック」（-fsanitize=safe-stack ）システムをサポートしています。 ^[33] Clangには、AddressSanitizer（）、^[6] UBSan（）、^[34] および非公式のSafeCode（LLVM 3.0で最後に更新された）という3つのバッファオーバーフロー検出器もあります。^[35]-fsanitize=address-fsanitize=bounds

これらのシステムは、パフォーマンスのペナルティ、メモリのオーバーヘッド、検出されたバグのクラスの点で異なるトレードオフを持っています。スタック保護は、OpenBSDを含む特定のオペレーティングシステムでは標準です。^[36]

IntelのCおよびC++コンパイラは、GCCやMicrosoft Visual Studioが提供するものと同様のオプションでスタックスマッシング保護をサポートしています。^[37]

Fail-Safe C ^[7]は、ファットポインタとオブジェクト指向のメモリアクセスに基づいて境界チェックを実行するオープンソースのメモリセーフANSI Cコンパイラです。^[38]

Mike Frantzen によって発明された StackGhost は、レジスタ ウィンドウのスピル/フィル ルーチンに簡単な調整を加えたもので、バッファ オーバーフローの悪用をはるかに困難にします。これは、Sun Microsystems SPARCアーキテクチャの独自のハードウェア機能 (遅延オンスタック インフレーム レジスタ ウィンドウ スピル/フィル) を使用して、戻りポインタの変更 (実行パスをハイジャックするエクスプロイトの一般的な方法) を透過的に検出し、バイナリまたはソースの変更を必要とせずにすべてのアプリケーションを自動的に保護します。パフォーマンスへの影響はごくわずかで、1% 未満です。結果として生じたgdb の問題は、2 年後に Mark Kettenis によって解決され、この機能が有効になりました。このイベントの後、StackGhost コードはOpenBSD /SPARCに統合 (および最適化) されました。

• 制御フローの整合性
• アドレス空間レイアウトのランダム化
• 実行可能スペースの保護
• メモリデバッガー
• 静的コード分析

• GCC 2003 サミット議事録 (PDF)
• 楽しみと利益のためにスタックを壊す ( Aleph One著)
• ProPolice 公式ホームページ
• Immunix StackGuard ホームページ
• USENIX Security 1998 の StackGuard オリジナル論文
• StackGhost: ハードウェアによるスタック保護
• FreeBSD 5.4 および 6.2 プロポリス実装
• StackShield と StackGuard の保護を回避する 4 つのトリック
• スタックスマッシングプロテクター