古いCコンパイラの使用はセキュリティリスクですか？

私たちには、誰も気にしないいくつかのビルドシステムが本番環境にあり、これらのマシンはGCC 3やGCC 2のようなGCCの古いバージョンを実行しています。

そして私はそれをより新しいものにアップグレードするよう経営陣を説得することはできません：彼らは「壊れていなければそれを修正しないでください」と言います。

私たちは非常に古いコードベース（80年代に書かれた）を維持しているため、このC89コードはこれらのコンパイラーで問題なくコンパイルされます。

しかし、私はこれらの古いものを使うのが良い考えだとは思いません。

私の質問は：

古いCコンパイラを使用すると、コンパイルされたプログラムのセキュリティが低下する可能性がありますか？

更新：

同じコードがVisual Studio 2008 for Windowsターゲットによってビルドされ、MSVCはまだC99またはC11をサポートしていません（新しいMSVCがサポートしているかどうかはわかりません）。最新のGCCを使用してLinuxボックスでビルドできます。したがって、新しいGCCをドロップするだけで、おそらく以前と同じように正常にビルドされます。

実際、私は反対を主張します。

C標準では動作が定義されていないが、特定のプラットフォームの「ダムコンパイラ」で何が起こるかは明らかな場合がいくつかあります。符号付き整数をオーバーフローさせたり、2つの異なる型の変数を介して同じメモリにアクセスしたりするような場合。

最近のバージョンのgcc（およびclang）では、これらのケースが、「未定義の動作」条件でのバイナリの動作を変更しても、最適化の機会として扱われ始めています。コードベースがCを「ポータブルアセンブラ」のように扱った人々によって作成された場合、これは非常に悪いことです。時間が経つにつれ、オプティマイザーはこれらの最適化を実行する際にコードのますます大きなチャンクを検討し始め、バイナリーが「ダムコンパイラーによってビルドされたバイナリー」が行うこと以外のことを実行する可能性が高まります。

「従来の」動作を復元するコンパイラスイッチ（上記の2つの場合の-fwrapvおよび-fno-strict-aliasing）がありますが、最初にそれらについて知る必要があります。

原則として、コンパイラのバグにより、準拠コードがセキュリティホールに変わる可能性がありますが、私はこれのリスクは大規模なスキームでは無視できると考えます。

両方の行動方針にはリスクがあります。

古いコンパイラーには成熟度の利点があり、それらで壊れたものはおそらく（ただし、保証はありません）正常に回避されています。

この場合、新しいコンパイラは新しいバグの潜在的な原因です。

一方、新しいコンパイラには追加のツールが付属しています。

• GCCとClangはどちらも、さまざまな種類の未定義の動作を検出するためにランタイムを計測できるサニタイザーを備えています（GoogleコンパイラチームのChandler Carruthは、昨年、完全なカバレッジに達したと期待していると主張しました）
• Clangは少なくとも強化機能を備えています。たとえば、制御フローの整合性は制御フローのハイジャックを検出することです。また、スタックスマッシング攻撃から保護するための強化実装もあります（スタックの制御フロー部分をデータ部分から分離することにより） ; 強化機能は一般的にオーバーヘッドが低い（CPUオーバーヘッドが1％未満）
• Clang / LLVMはlibFuzzerにも取り組んでいます。これは、テスト中の関数の入力スペースをスマートに探査するインストゥルメント化されたファジングユニットテストを作成するツールです（まだ探査されていない実行パスを取得するために入力を微調整することにより）

バイナリをサニタイザー（アドレスサニタイザー、メモリサニタイザー、または未定義の動作サニタイザー）で計測してファジングすると（たとえば、アメリカのファジーロップを使用して）、多くの注目を集めているソフトウェアの脆弱性が発見されました。たとえば、このLWN.netの記事を参照してください。

これらの新しいツール、および将来のすべてのツールは、コンパイラーをアップグレードしない限りアクセスできません。

パワー不足のコンパイラーにとどまることで、脆弱性が発見されない砂浜に頭を抱え、指を交差させています。あなたの製品が価値の高いターゲットである場合、私はあなたに再考することをお勧めします。

注：実動コンパイラーをアップグレードしない場合でも、とにかく新しいコンパイラーを使用して脆弱性をチェックすることをお勧めします。ただし、これらは異なるコンパイラであるため、保証は少なくなります。

コンパイルされたコードには、悪用される可能性のあるバグが含まれています。バグは3つのソースから発生します。ソースコードのバグ、コンパイラとライブラリのバグ、およびコンパイラがバグに変換するソースコードの未定義の動作です。（未定義の動作はバグですが、コンパイル済みコードのバグではありません。例として、i = i ++; CまたはC ++ではバグですが、コンパイル済みコードでは、iが1増加し、OKまたは設定される場合があります私はいくつかのジャンクになり、バグになります）。

コンパイルされたコードのバグの発生率は、テストと顧客のバグレポートによるバグの修正により、おそらく低くなっています。したがって、最初は多数のバグがあった可能性がありますが、それは減少しました。

新しいコンパイラにアップグレードすると、コンパイラのバグによって導入されたバグが失われる可能性があります。しかし、これらのバグはすべて、あなたの知る限り誰も発見せず、誰も利用していないバグです。しかし、新しいコンパイラー自体にバグがある可能性があり、重要なことに、新しいコンパイラーは未定義の動作をコンパイル済みコードのバグに変える傾向が強いです。

したがって、コンパイルされたコードには多くの新しいバグが含まれます。ハッカーが見つけて悪用できるすべてのバグ。そして、多くのテストを行い、コードを顧客に残してバグを長期間見つけさせない限り、安全性は低下します。

壊れていない場合は修正しないでください

あなたの上司はこれを正しいと言っていますが、より重要な要素は、入力、出力、バッファオーバーフローの保護です。それらの欠如は、使用されるコンパイラーに関係なく、常にその観点からチェーンの最も弱いリンクです。

ただし、コードベースが古く、型の安全性の欠如、安全でないfgetsなど、使用されているK＆R Cの弱点を軽減するための作業が行われた場合、「コンパイラーをより最新のC99にアップグレードするか/ C11標準はすべてを壊しますか？」

副作用を引き起こす可能性がある新しいC標準に移行する明確なパスがあることを条件として、古いコードベースのフォークを試み、それを評価して、追加の型チェック、サニティチェックを行い、アップグレードするかどうかを決定するのが最善です。新しいコンパイラは、入力/出力データセットに影響を与えます。

次に、上司にそれを示すことができます。「これは、業界で認められているC99 / C11標準に沿った、より新しいリファクタリングされたコードベースです...」です。

それは、上に計量しなければならないギャンブルだ非常に慎重に、変化にresistenceは、その環境であっ表示されることがありますし、新しいものに触れることを拒否することがあります。

編集

K＆Rで生成されたコードは16ビットプラットフォームで実行できる可能性があり、K＆Rで生成されたコードは実際にコードベースを壊す可能性があります。アーキテクチャの観点から考えると、32ビットコードが生成されます。 、これは、入出力データセットに使用される構造に面白い副作用をもたらす可能性があります。これは、慎重に検討する必要があるもう1つの大きな要因です。

また、OPはVisual Studio 2008を使用してコードベースを構築することを述べているため、gccを使用するとMinGWまたはCygwinのいずれかが環境に導入され、環境に影響を与える可能性があります。ただし、ターゲットがLinuxの場合を除き、ショットの価値があります。古いK＆Rコードベースのノイズを最小限に抑えるためにコンパイラへの追加のスイッチを含める必要がある場合があります。他の重要なことは、機能が壊れていないことを確認するために多くのテストを実行することです。

古いCコンパイラを使用すると、コンパイルされたプログラムのセキュリティが低下する可能性がありますか？

もちろん、古いコンパイラに既知のバグが含まれていて、プログラムに影響を与えることがわかっている場合は可能です。

問題は、それですか？確実に知るには、バージョンから現在の日付までの変更ログ全体を読み、長年にわたって修正されたすべてのバグを確認する必要があります。

プログラムに影響を与えるコンパイラのバグの証拠が見つからない場合、GCCを更新することは、それがちょっと偏執的であるように思われます。新しいバージョンには、まだ発見されていない新しいバグが含まれている可能性があることに注意してください。GCC 5とC11のサポートにより、最近多くの変更が行われました。

そうは言っても、80年代に記述されたコードは、コンパイラに関係なく、セキュリティホールと不十分に定義された動作への依存ですでにいっぱいになっている可能性が高いです。ここでは、先行標準のCについて話しています。

悪意のある開発者がコンパイラのバグを介してバックドアをこっそり侵入できるというセキュリティ上のリスクがあります。使用中のコンパイラの既知のバグの量によっては、バックドアが目立たないように見える場合があります（いずれにしても、ポイントは、コードが複雑であっても、ソースレベルで正しいということです。ソースコードのレビューとテストバグのないコンパイラは、これらの条件ではバックドアが存在しないため、バックドアを検出しません。追加の否認可能性ポイントについては、悪意のある開発者は、以前に知られていないコンパイラのバグを自分で探すこともあります。この場合も、カモフラージュの品質は、見つかったコンパイラバグの選択によって異なります。

この攻撃は、この記事のプログラムsudoで説明されています。bcryptはJavascript minifiersのすばらしいフォローアップを書きました。

別にこの懸念から、Cコンパイラの進化は未定義の動作を活用することであった以上と多くのと、より積極的に、誠実に書かれていたので、古いCコードは、実際にはより多くの時間から、Cコンパイラでコンパイル、またはでコンパイルされ、安全なことになります-O0（ただし、新しいバージョンのコンパイラーでは、-O0でも、プログラムを壊すUBを悪用する最適化がいくつか導入されています）。

古いコンパイラには、既知のハッキング攻撃に対する保護機能がない場合があります。たとえば、スタック破壊保護はGCC 4.1まで導入されませんでした。つまり、古いコンパイラでコンパイルされたコードは、新しいコンパイラが保護する方法で脆弱になる可能性があります。

心配するもう1つの側面は、新しいコードの開発です。

古いコンパイラは、一部の言語機能について、プログラマが標準化および期待しているものとは異なる動作をする場合があります。この不一致により、開発が遅くなり、悪用可能な微妙なバグが発生する可能性があります。

古いコンパイラは提供する機能が少なく（言語機能を含む！）、最適化もされていません。プログラマーはこれらの欠陥を回避するためにハッキングします。たとえば、不足している機能を再実装したり、あいまいであるが高速に実行される巧妙なコードを記述したりして、微妙なバグを作成する新しい機会を作り出します。

いや

その理由は単純です。古いコンパイラには古いバグとエクスプロイトがあるかもしれませんが、新しいコンパイラには新しいバグとエクスプロイトがあります。

新しいコンパイラにアップグレードして、バグを「修正」しない。古いバグとエクスプロイトを新しいバグとエクスプロイトに切り替える。

新しいコンパイラーを使用するのではなく、古いコンパイラーのバグがよく知られ、文書化されている可能性が高いので、それらのバグを回避してコーディングすることで、それらのバグを回避するためのアクションを実行できます。したがって、アップグレードの引数としては不十分です。私が作業しているのと同じ議論があります。組み込みソフトウェアのコードベースでGCC 4.6.1を使用します。新しい文書化されていないバグを恐れて、最新のコンパイラにアップグレードすることは（管理の中でも）非常に躊躇しています。

あなたの質問は2つの部分に分かれます：

• 露骨な表現：「古いコンパイラを使用することでリスクが高まるか」（タイトルのように多少異なる）
• 暗黙的：「経営陣にアップグレードを説得するにはどうすればよいですか」

おそらく、既存のコードベースで悪用可能な欠陥を見つけ、より新しいコンパイラがそれを検出したことを示すことで、両方に答えることができます。もちろん、あなたの経営陣は「古いコンパイラでそれを見つけた」と言うかもしれませんが、かなりの労力がかかることを指摘できます。または、新しいコンパイラーを介して実行して脆弱性を見つけ、それを悪用します（新しいコンパイラーでコードをコンパイルできる/許可されている場合）。友好的なハッカーの助けが必要かもしれませんが、それは彼らを信頼し、コードを表示できる（または新しいコンパイラを使用できる）かどうかに依存します。

ただし、システムがハッカーにさらされていない場合は、コンパイラのアップグレードによって効果が向上するかどうかにもっと関心を持つ必要があります。MSVS2013コード分析は、MSVS 2010よりもはるかに早く潜在的なバグを検出し、多かれ少なかれC99 / C11をサポートします–正式に実行されるかどうかは不明ですが、宣言はステートメントの後に続き、変数はfor-loopsで宣言できます。