バッファ・オーバーフローを検出、防止、緩和する方法

バッファ・オーバーフローの検出

以上の定義を踏まえておけば、このような欠陥の検出方法を検討することができます。ソースコードを操作する際の簡単なバッファ・オーバーフロー対策は、バッファを使用、変更、アクセスする箇所に特別な注意を払うことです。ユーザーなどの外部ソースによって指定された入力を処理する関数は、オーバーフローを悪用しやすいベクトルとなるため特に注意が必要です。たとえば、次の例に示すように、ユーザーに「はい」または「いいえ」を問う処理の場合、”yes”という文字列が収まるだけの小さいバッファにユーザーの文字列入力を格納するとします。

バッファ・オーバーフローの防止

ソースコード内のバッファ・オーバーフロー脆弱性を検出する機能は確かに有益ですが、コードベースから脆弱性を排除するには、着実な検出、およびセキュアなバッファ処理方法への習熟が必要です。バッファ・オーバーフロー脆弱性を防止する最も簡単な方法は、脆弱性が入り込む余地のない言語を使用することです。C言語は、メモリーに直接アクセスし、厳密なオブジェクト型が存在しないという性質により脆弱性の余地があります。これらの要素を持たない言語は一般に脆弱性の影響を受けません。Java、Python、.NETなどの言語やプラットフォームでは、オーバーフロー脆弱性を緩和するための特別なチェックや変更は不要です。

とはいえ、開発言語を全面的に変更することが常に可能とは限りません。その場合には、セキュアな方法でバッファを処理します。文字列処理関数については、使用可能なメソッド、安全なメソッド、回避すべきメソッドについて多くの議論がなされてきました。strcopyはバッファに文字列をコピーする関数、strcatはバッファの内容を別のバッファの内容に追加する関数です。この2つの関数はターゲット・バッファの境界をチェックせず、指定されたデータのバイト数がバッファより大きい場合にはバッファの制限を超えて書き込みを行うため、その動作は安全ではありません。

代わりに、それぞれの関数のstrn-バージョンが一般に推奨されます。strn-バージョンは、ターゲット・バッファの最大のサイズまでのデータのみを書き込みます。これは理想的な解決策のように思われるかもしれませんが、これらの関数にも問題を引き起こす可能性を伴う微妙な差異があります。データがバッファの制限に到達した場合、バッファの最後のバイトに終端文字が存在しないと、次のようなデータを読み取ったときに大きな問題が生じる可能性があります。

バッファ・オーバーフローの緩和

安全でない関数がオーバーフローに見舞われる余地を残している場合でも、他に手立てがないわけではありません。コンパイルまたは実行時にオーバーフロー脆弱性を検出するための改善が進んでいます。プログラムを実行すると、多くの場合、コンパイラはカナリアと呼ばれるランダムな値を作成してスタック上の各バッファの後に配置します。カナリアが炭坑の危険を知らせる鳥であったように、その名を冠したカナリアの値は危険を警告します。カナリアの値を元の値と比較してチェックすることにより、バッファ・オーバーフローが発生しているかどうかを確認できます。値が変更されていた場合、変更された可能性があるリターン・アドレスに戻って処理を続行するのではなく、プログラムを停止またはエラー状態にすることができます。

最近のオペレーティング・システムの中には、非実行可能スタックやアドレス空間配置のランダム化（ASLR : Address Space Layout Randomization）の形で防御が強化されているものがあります。非実行可能スタック（データ実行防止：DEP)では、スタックおよび場合によってはその他の構造体をコード実行不可能な領域としてマークします。これにより、攻撃者はエクスプロイト・コードをスタックに挿入して実行を成功させることを期待できなくなります。

ASLRは、リターン指向プログラミング（ROP）（既存の断片的なコードがメモリー上のアドレスのオフセットに基づいて連結される非実行可能スタックを回避する手法）に対する防御を目的に開発されました。この機能は構造体のメモリー上の配置をランダム化することによってオフセットを特定し難くします。このような防衛策が1980年代後半に存在していれば、モリス・ワームは防止できたかもしれません。その理由は、モリス・ワームにはエクスプロイト・コードでUNIX fingerdプロトコルを用いてバッファにデータを設定し、そのバッファをオーバーフローさせて、エクスプロイト・コードが設定されているバッファを指定するようにリターン・アドレスを変更することによって機能していたという側面があるためです。ASLRとDEPを用いることで、メモリー領域を完全に実行不可にすることはできないまでも、指定するアドレスの特定は難しくなります。

開発、コンパイラ、オペレーティング・システムのレベルで対策を講じていても、脆弱性が見過ごされて攻撃の余地が残る場合があります。バッファ・オーバーフローが存在する最初の兆候の段階でエクスプロイトが成功することもあります。このような場合には、遂行しなければならない重要な課題が2つあります。最初に、脆弱性を特定し、コードベースを変更して問題を解決する必要があります。次は、コードの脆弱なバージョンのすべてを、パッチを適用した新しいバージョンに確実に置き換えることが目標になります。それには、インターネットに接続し、該当のソフトウェアを実行するすべてのシステムに及ぶ自動更新から始めることが理想的です。

しかし、自動更新で十分にカバーされることを前提にするわけにはいきません。組織または個人がインターネットへの制限付きアクセスでシステム上のソフトウェアを使用する場合があります。その場合には手動による更新が必要です。そのためには、該当ソフトウェアを使用している可能性があるすべての管理者に更新に関する情報を配信し、パッチを簡単にダウンロードできるようにする必要があります。パッチの作成と配布は脆弱性の発見後できるだけ早急に行い、ユーザーやシステムが脆弱性にさらされる時間を最短に抑えることをお勧めします。

コンパイラやオペレーティング・システムの安全なバッファ処理関数および適切なセキュリティ機能を使用することにより、バッファ・オーバーフローに対する堅牢な防衛手段を構築できます。こうした手順を踏まえた上でなお、エクスプロイトを防ぐには欠陥を着実に特定するステップが重要です。ソースコードの各行を丹念に調べてバッファ・オーバーフローの可能性を探す作業は骨が折れます。しかも、人間の目視では常に見落としが生じる可能性があります。そこで、開発時のセキュリティ脆弱性の検出専用に、コード品質を強化するための静的解析ツール（linterに似た機能）が開発されました。

たとえば、Coverity Code Advisorはバッファ・オーバーフローの可能性に対するレッドフラグ（危険信号）を特定します。特定されたレッドフラグをトリアージ（優先順位付け）して個別に修正できるため、コードベースを手動で探す必要がありません。これらのツールと定期的なコードレビュー、バッファ・オーバーフローへの対処方法に関する知識を組み合わせることにより、コードの開発が完了する前の段階でバッファの欠陥の大部分を特定し、緩和することが可能になります。