コンパイラフラグを使用してライブラリから未使用の機能を削除すると、セキュリティリスクが増加または減少しますか？
組み込みシステムなどのリソースに制約のある環境をターゲットとするソフトウェアライブラリは、条件付きコンパイルを使用して、コンシューマーがスペースを節約できるようにし、本番環境で配布される最終的なバイナリから未使用の機能を削除してパフォーマンスを向上させます。
ライブラリ開発者がコンパイラフラグを作成し、ライブラリの設計およびテスト段階で考慮されたと想定します。
ほとんどの設計決定にはトレードオフがあり、この場合、設計およびテスト対象のブランチが増えるため、コードの複雑さと製品品質は間違いなく影響を受けます。
ただし、セキュリティに関しては、最終的な影響は明確ではなく、機能の削除によるプラスとマイナスの両方の影響があります。最初は、コードを削除することで、攻撃の対象となる領域を減らします。しかし、その一方で、カスタムバイナリをビルドするということは、その特定の組み合わせにバグが存在し、したがって悪用される可能性があることを意味します。
2つの異なるタイプの分岐が考慮されているだけでなく、コンパイラー条件構文はランタイムの対応する構文よりも安全ではない（少なくともCでは）ため、従来のランタイムパスの複雑さとは異なります。
興味深い現象は、カスタムバイナリをビルドするとユーザーが標的型攻撃にさらされる可能性がありますが、標準ビルドを使用するとユーザーが大量に悪用される可能性があることです。
問題は、セキュリティにプラスとマイナスの両方の影響があることを考えると、それらを定量化した場合、正味の影響はプラスかマイナスか？もう1つは、学問的ではない言葉ですが、セキュリティに関心がある場合、必要な機能なしでカスタムバイナリを作成する必要がありますか？
この質問を引き起こした具体的な例は、Busyboxが条件付きでコンパイルされた機能フラグを多用していることです。 https://git.busybox.net/busybox/tree/networking/httpd.c
一般的に言って、それはセキュリティリスクを減らします。
未使用の機能がある場合は常に、一部の攻撃者がそれらをアクティブ化する方法を見つけ、テストしていないコードを実行する可能性があります。
ただし、コードが最初から堅牢に記述されていない場合、新しいセキュリティの脆弱性が生じる可能性があります。機能を削除するためのコンパイラフラグを持つライブラリは、削除された機能の任意の組み合わせで適切に機能するように設計されていると想定するのが妥当です。これは、ライブラリを使用するコードには当てはまらない場合があります。
多くのコードは、呼び出しが失敗しないと開発者が考えるときに、ライブラリ呼び出しからのエラーをチェックしません。 「失敗できない」という呼び出しが突然失敗した場合、予期しないセキュリティ上の影響が生じる可能性があります。たとえば、 ある時点で、Linuxプログラムsendmailはsetuid呼び出しからのエラーをチェックしませんでした で、プログラムは別のプログラムの特権を引き受けることができますユーザー。攻撃者がsetuidを失敗させた場合、sendmailは攻撃者の権限を持っているはずのroot権限を持つことになります。攻撃者は、自分のファイルだけでなく、ファイルシステムの任意の場所にあるファイルにアクセスする可能性があります。脆弱性の説明では、sendmailを使用してファイルにアクセスする方法を正確に説明していません。
別の特殊なケースは、プロトコルバージョンのネゴシエーションが含まれる場合です。 TLS 1.3をサポートするTLSライブラリがあり、TLS 1.3をサポートするサーバーに接続している場合、TLS 1.3を使用してサーバーに接続します。ただし、TLS 1.3と1.2および1.1と1.0のサポートを無効にした場合、サーバーで許可されていれば、ライブラリはSSL 3.0を使用してサーバーに接続する可能性があります。これは [〜＃〜]と呼ばれる攻撃に対して脆弱ですプードル[〜＃〜] 。 （すべてのoldプロトコルを無効にすることにより、この可能性を軽減する必要があります-もう一度-セキュリティを向上させます）
一般的に言って、それはセキュリティリスクを増大させます。
何らかの機能フラグがあり、単一のプログラムがなくなった場合は常に、2つ以上のプログラムがあります。
各プログラムにはバグがある可能性があるため、1つのコンパイルフラグでリスクが2倍になる可能性があります。
これで明らかに、特定のプログラム/機能フラグセットを分析し、プログラムの一部のみが影響を受けるため、実際のリスクが2倍にならないことがわかります。しかし、私はそのような数学的に証明された静的分析が標準ではないことを思いつきます。
ボールパーキングリスクだけの場合は、テストしていないバグがあると想定する必要があります。小さな機能フラグのように見えても、プログラムの無関係に見える部分に影響を与え、それらのリスクを考慮する必要があります。