web-dev-qa-db-ja.com

GCCがC / C ++をコンパイルするための最も強化されたオプションのセットは何ですか？

GCCオプションのどのセットが、バッファーオーバーフローやダングリングポインターなどのメモリ破損の脆弱性に対する最良の保護を提供しますか？ GCCは、あらゆるタイプのROPチェーン緩和策を提供しますか？このGCCオプションがミッションクリティカルなアプリケーションで機能しなくなるパフォーマンスの問題やその他の問題はありますか？

Debian Hardening Guide と GCC Mudflap を見ています。以下は、私が検討している次の構成です。

-D_FORTIFY_SOURCE=2
-fstack-protector --param ssp-buffer-size=4
-fPIE -pie
-Wl,-z,relro,-z,now (ld -z relro and ld -z now)

このオプションのセットにできる改善点はありますか？

WebKitの保護について最も心配しています。

buffer-overflowgccc++
64
rook

私はgccをコーディングしていないので、誰か他の人がこれに追加したり、修正したりできるといいのですが。返信で編集します。これらの一部は、すべての状況で機能するわけではありません。

  • -壁-Wextra
    すべての警告をオンにして、基盤となるコードが安全であることを確認します。

  • -Wconversion -Wsign-conversion
    unsign/sign変換に関する警告。

  • -Wformat­-security
    起こり得るセキュリティの問題を表すフォーマット関数の使用について警告します。

  • -Werror
    すべての警告をエラーに変えます。

  • -Arch x86_64
    アドレス空間を最大限に活用するために64ビット用にコンパイルします（ASLRにとって重要です。レイアウトをランダム化するときに選択できる仮想アドレス空間が増えます）。

  • -mmitigate-rop
    意図しない戻りアドレスなしでコードをコンパイルしようとするため、ROPが少し難しくなります。

  • -mindirect-branch = thunk -mfunction-return = thunk
    retpoline （トランポリンを返す）を有効にして、Spectre V2の一部のバリアントを軽減します。 2番目のフラグは、ブランチターゲットバッファが脆弱であるため、Skylake +で必要です。

  • -fstack-protector-all -Wstack-protector --param ssp-buffer-size = 4
    「-fstack-protector」を選択しても、すべての機能が保護されるわけではありません（コメントを参照）。すべての関数にガードが適用されることを保証するには、-fstack-protector-allが必要ですが、これによりパフォーマンスが低下する可能性があります。 -fstack-protector-strong を中立と考えてください。
    ここでの-Wstack-protectorフラグは、保護されない関数に対して警告を与えます。

  • -fstack-clash-protection
    スタッククラッシュ と呼ばれる攻撃のクラスを打ち破ります。

  • -pie -fPIE
    ASLRの完全なセキュリティ上の利点を取得するために必要です。

  • -ftrapv
    署名付きオーバーフローのトラップを生成します（現在、gccで bugged であり、UBSANに干渉する可能性があります）。

  • -D_FORTIFY_SOURCE = 2
    バッファオーバーフローチェック。 = 2と= 1の違い も参照してください。

  • -Wl、-z、relro、-z、now
    RELRO（読み取り専用の再配置）。一緒に指定されたオプションrelro＆nowは、「フルRELRO」と呼ばれます。 nowフラグを省略すると、「部分RELRO」を指定できます。 RELROはさまざまなELFメモリセクションを読み取り専用としてマークします（例 [〜＃〜] got [〜＃〜] ）。

  • -Wl、-z、noexecstack
    非実行可能なスタック。このオプションは、スタックを実行不可にマークします。これは、多くのコードと互換性がない可能性がありますが、起こり得るコード実行に対して多くのセキュリティを提供します。 （ https://www.win.tue.nl/~aeb/linux/hh/protection.html ）
  • -fvtable-verify = [std | preinit | none]
    Vtableポインターの検証。これにより、実行時に、すべての仮想呼び出しについて、呼び出しに使用されたvtableポインターがオブジェクトのタイプに対して有効であり、破損または上書きされていないことを確認できます。実行時に無効なvtableポインターが検出されると、エラーが報告され、プログラムの実行が直ちに停止します。（ https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html =）
  • -fcf-protection = [full | branch | return | none]
    制御フロー転送のコードインストルメンテーションを有効にして、制御フロー転送命令（間接関数呼び出し、関数戻り、間接ジャンプなど）のターゲットアドレスが有効であることを確認して、プログラムのセキュリティを向上させます。 IntelのCETを搭載したx86（_64）でのみ使用できます。（ https://gcc.gnu.org/onlinedocs/gcc/Instrumentation- Options.html ）

Windowsでコンパイルする場合、Windowsの一部の保護（SEHOPなど）はGCCの一部ではないため、GCCではなくVisual Studioを使用してください。ただし、GCCを使用する必要がある場合：

  • -Wl、dynamicbase
    リンカにASLR保護を使用するように伝えます。
  • -Wl、nxcompat
    リンカにDEP保護を使用するように伝えます。
53
0xdabbad00

これらは良いオプションですが、あなた自身のソースコードに注意を払う必要があります。ユーザー入力を処理するときは安全な関数を使用し、それらをフィルタリングしてください。また、strncpy（）などを使用するときは、特定の攻撃を防ぐために多くのスペースを与えないようにしてください。 OS自体がセキュリティ、つまりDEP（NX）、ASLR、カナリアを提供してスタックを保護しますが、常にそれらに依存することはできません。だから、ええ、上記は私の提案です。少しお役に立てば幸いです。ソースコード監査ツールも使用できます。幸運を！

4
3ntr0py