GCCのスタック保護機能をいつどのように使用しますか？
作業中のプロジェクトのコンパイル時に-Wstack-protector警告を有効にしました（商用のマルチプラットフォームC++ゲームエンジン、GCC 4.2を搭載したMac OS X 10.6でコンパイル）。このフラグは、-fstack-protectorが有効になっていても、スタックの破壊から保護されない関数について警告します。 GCCは、プロジェクトをビルドするときに警告を発します。
機能を保護しない：少なくとも8バイト長のバッファーなし
ローカル変数を保護しない：可変長バッファー
最初の警告では、関数で使用するときにバッファが持つ必要がある最小サイズを調整できることがわかりました。この関数をスタックスマッシングから保護するには、--param ssp-buffer-size=Xを使用できます。Xは8デフォルトであり、1に設定できます。
2番目の警告については、-Wstack-protectorの使用を停止しない限り、その発生を抑制することはできません。
- いつ
-fstack-protectorを使用する必要がありますか？ （たとえば、開発中に常に、またはバグを追跡するだけですか？） - いつ
-fstack-protector-allを使用する必要がありますか？ -Wstack-protectorとは何ですか？バッファーの最小サイズを小さくすることを示唆していますか？- その場合、サイズを1に設定することのマイナス面はありますか？
- 警告のないビルドが必要な場合、
-Wstack-protectorは常に有効にしたい種類のフラグではないようです。これは正解？
スタック保護は強化戦略であり、デバッグ戦略ではありません。ゲームがネットワーク対応であるか、制御されていないソースからのデータがある場合は、オンにします。制御されていない場所からのデータがない場合は、オンにしないでください。
以下がその方法です：バグがあり、攻撃者が制御できるものに基づいてバッファーを変更した場合、その攻撃者はリターンアドレスまたはスタックの同様の部分を上書きして、コードの代わりにコードを実行させることができます。スタック保護は、これを検出するとプログラムを中止します。ユーザーは満足しませんが、ハッキングされることもありません。これはゲーム内での不正行為に関するハッキングではなく、コードの脆弱性を使用してユーザーに感染する可能性のあるエクスプロイトを作成するハッキングのようなものです。
デバッグ指向のソリューションについては、mudflapなどをご覧ください。
特定の質問に関して：
- 制御されていないソースからデータを取得する場合は、スタックプロテクターを使用します。これに対する答えはおそらくイエスです。それを使用します。制御されていないソースからのデータを持っていなくても、おそらく最終的にまたはすでにそれを理解していないでしょう。
パフォーマンスの低下と引き換えに追加の保護が必要な場合は、すべてのバッファーのスタック保護を使用できます。 gcc4.4.2マニュアル から：
-fstack-protector
スタックスマッシング攻撃などのバッファオーバーフローを確認するための追加コードを生成します。これは、脆弱なオブジェクトを持つ関数にガード変数を追加することにより行われます。これには、allocaを呼び出す関数、および8バイトを超えるバッファーを持つ関数が含まれます。ガードは、関数に入るときに初期化され、関数が終了するときにチェックされます。ガードチェックが失敗すると、エラーメッセージが出力され、プログラムが終了します。
-fstack-protector-all
すべての機能が保護されることを除いて、-fstack-protectorと同様です。
警告は、スタック保護で保護できないバッファを示します。
- 必ずしも最小バッファーサイズを小さくすることを提案しているわけではなく、0/1のサイズでは、stack-protector-allと同じです。バッファが保護されるようにコードを再設計することを決定した場合に、できるようにするためだけにそれを指摘しています。
- いいえ、これらの警告は問題を表すものではなく、単に情報を示しているだけです。定期的に使用しないでください。
実際、通常のビルドでは警告を気にする必要はありません。それは本当に情報メッセージです。スタック上の可変サイズのバッファに固有のセキュリティ上の懸念があることは明らかであることを願っています。サイズの計算が間違っていて、大きな穴が開いています。