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

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

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

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

ランダムXORカナリアとは、制御データの全部または一部を用いてXOR演算によってランダムにスクランブルされたカナリアのことです。このようにして、カナリアまたは制御データが一度でも改ざんされると、カナリアの値は誤った値になります。

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

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

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

スタック破壊保護は、 1997 年にStackGuardによって初めて実装され、1998 年のUSENIX Security Symposiumで発表されました。^{[ 11 ]} StackGuard は、 GCC 2.7の Intel x86 バックエンドへのパッチのセットとして導入されました。StackGuard は 1998 年から 2003 年までImmunix Linux ディストリビューション向けに維持され、ターミネータ、ランダム、ランダム XOR カナリアの実装で拡張されました。StackGuard は、GCC 2003 Summit Proceedings ^{[ 12 ]}で GCC 3.x への組み込みが提案されましたが、これは実現しませんでした。

IBMは2001年から2005年にかけて、スタック破壊防止のためのGCCパッチであるProPoliceを開発しました。^{[ 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 Core 5 以降、すべてのFedoraパッケージは でコンパイルされており、 Fedora 20 以降はでコンパイルされています。 ^{[ 19 ] [ 20 ]} Ubuntuのほとんどのパッケージは6.10 以降でコンパイルされています。^{[ 21 ]} Arch Linux のすべてのパッケージは2011 以降でコンパイルされています。 ^{[ 22 ]} 2014 年 5 月 4 日以降にビルドされたすべての Arch Linux パッケージは を使用しています。^{[ 23 ]}スタック保護はDebianの一部のパッケージでのみ使用され、^{[ 24 ]} FreeBSDベース システム 8.0 以降でのみ使用されます。^{[ 25 ]}スタック保護はOpenBSD、^{[ 26 ]} Hardened Gentoo ^{[ 27 ]}およびDragonFly BSDなど、特定のオペレーティングシステムで標準となっています。-fstack-protector-fstack-protector-strong-fstack-protector-fstack-protector-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 用に最後に更新) ^{[ 35 ]という 3 つのバッファオーバーフロー検出器もあります。}-fsanitize=address-fsanitize=bounds

これらのシステムは、パフォーマンスの低下、メモリのオーバーヘッド、検出されるバグの種類に関して、それぞれ異なるトレードオフを持っています。スタック保護は、OpenBSDを含む特定のオペレーティングシステムで標準となっています。^{[ 36 ]}

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

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

マイク・フランツェンによって考案されたStackGhostは、レジスタウィンドウのスピル・フィルルーチンに簡単な変更を加えることで、バッファオーバーフローの悪用をはるかに困難にするものです。これは、 Sun Microsystems SPARCアーキテクチャの独自のハードウェア機能である、遅延実行、オンスタック、インフレームのレジスタウィンドウ・スピル・フィルを利用して、リターンポインタの変更（エクスプロイトが実行パスを乗っ取る一般的な方法）を透過的に検出し、実行ファイルやソースコードを変更することなく、すべてのアプリケーションを自動的に保護します。パフォーマンスへの影響はごくわずかで、1%未満です。発生したgdbの問題は、2年後にマーク・ケッテニスによって解決され、この機能が有効になりました。この出来事の後、StackGhostのコードはOpenBSDオペレーティングシステムのSPARC版に統合（および最適化）されました。