8

バッファオーバーフロー攻撃を防ぐためのアイデアは何ですか?Stackguardについて聞いたことがありますが、これまで、この問題は、Stackguardを適用するか、他の手法と組み合わせることで完全に解決されましたか?

ウォームアップ後、経験豊富なプログラマーとして

バッファオーバーフロー攻撃に対して適切な防御を提供することが非常に難しいと思うのはなぜですか?

編集:すべての回答に感謝し、セキュリティタグをアクティブに保ちます:)

4

6 に答える 6

4

できることはたくさんあります。順不同...

まず、言語の選択が、ダイレクトメモリアクセスを許可する言語と許可しない言語の間で均等に分割されている(またはほぼ均等に分割されている)場合は、許可しない言語を選択します。つまり、C / C ++ではなくPerl、Python、Lisp、Javaなどを使用します。これは常にオプションであるとは限りませんが、足を撃たないようにするのに役立ちます。

次に、メモリに直接アクセスできる言語では、std :: stringのようにメモリを処理するクラスが利用できる場合は、それらを使用します。ユーザー数が少ないクラスよりも、十分に練習したクラスを優先します。より多くの使用は、より単純な問題が通常の使用で発見される可能性が高いことを意味します。

第三に、ASLRやDEPなどのコンパイラオプションを使用します。アプリケーションが提供するセキュリティ関連のコンパイラオプションを使用します。これはバッファオーバーフローを防ぐことはできませんが、オーバーフローの影響を軽減するのに役立ちます。

第4に、Fortify、Qualys、Veracodeのサービスなどの静的コード分析ツールを使用して、コーディングするつもりのないオーバーフローを検出します。次に、発見されたものを修正します。

第5に、オーバーフローがどのように機能するか、およびコードでオーバーフローを見つける方法を学びます。すべての同僚もこれを学ぶ必要があります。オーバーラン(およびその他の脆弱性)がどのように機能するかについて人々を訓練することを要求する組織全体のポリシーを作成します。

第6に、通常のコードレビューとは別に安全なコードレビューを行います。定期的なコードレビューにより、コードが機能し、機能テストに合格し、コーディングポリシー(インデント、命名規則など)を満たしていることを確認します。安全なコードレビューは、具体的には明示的に意図されており、セキュリティの問題を探すことのみを目的としています。可能なすべてのコードに対して安全なコードレビューを行います。優先順位を付ける必要がある場合は、ミッションクリティカルなもの、問題が発生する可能性のあるもの(信頼の境界を越える(データフロー図と脅威モデルについて学び、それらを作成する)、インタープリターが使用される場所、特にユーザー入力が渡される場所)から始めます。データベースから取得したデータを含む、保存/取得)。

第七に、お金があれば、Neohapsis、VSR、Matasanoなどの優れたコンサルタントを雇って製品をレビューしてください。彼らはオーバーランよりもはるかに多くのものを見つけるでしょう、そしてあなたの製品はそれのためにすべてより良いでしょう。

第8に、QAチームが、オーバーランがどのように機能し、どのようにテストするかを知っていることを確認します。QAには、すべての入力でオーバーランを検出するように特別に設計されたテストケースが必要です。

第九に、ファジングを行います。ファジングは、多くの製品で驚くほど多くのオーバーフローを検出します。

追加するために編集:質問を読み間違えました。タイトルには「テクニックは何ですか」と書かれていますが、テキストには「なぜ難しいのか」と書かれています。

間違えやすいので難しいです。オフバイワンエラーや数値変換などの小さな間違いは、オーバーフローにつながる可能性があります。プログラムは複雑な相互作用を伴う複雑な獣です。複雑なところには問題があります。

または、質問を元に戻すために、バグのないコードを書くのが難しいのはなぜですか?

于 2010-09-14T02:22:46.773 に答える
2

バッファオーバーフローの悪用を防ぐことができます。プログラマーが完璧であれば、チェックされていないバッファーはなく、その結果、バッファーオーバーフローの悪用はありません。ただし、プログラマーは完璧ではなく、チェックされていないバッファーが引き続きたくさんあります。

于 2010-09-14T01:43:27.300 に答える
2

必要な手法は1つだけです。外部ソースからのデータを信頼しないでください。

于 2010-09-14T02:08:03.583 に答える
2

セキュリティに特効薬はありません。慎重に設計し、慎重にコーディングし、コードレビューを実施し、テストし、脆弱性が発生したときに修正するように手配する必要があります。

幸いなことに、バッファオーバーフローの特定のケースは、長い間解決された問題でした。ほとんどのプログラミング言語には配列境界チェックがあり、プログラムがポインタを構成することはできません。CやC++など、バッファオーバーフローを許可する少数のものは使用しないでください。

もちろん、これは組み込みファームウェア¹からアプリケーションまでのソフトウェアスタック全体に適用されます。

¹関連するテクノロジーに精通していない場合、このエクスプロイトにより、ネットワーク上の攻撃者が目を覚まし、電源がオフになっているコンピューターを制御する可能性があります。(通常のファイアウォール構成は、問題のあるパケットをブロックします。)

于 2010-09-15T07:21:47.310 に答える
1

アナライザーを実行して、コードが本番環境に入る前に問題を見つけるのに役立てることができます。私たちのメモリ安全チェッカーは、コードをインストルメント化してミスが発生したときにそれを監視することにより、Cコードのバッファーのオーバーアン、不正なポインターの障害、配列アクセスのエラー、およびメモリー管理のミスを検出します。Cプログラムがこのようなエラーの影響を受けないようにする場合は、メモリ安全性アナライザーの結果をコードの製品版として使用できます。

于 2011-03-10T15:22:13.973 に答える
0

現代の搾取では、大きな3つは次のとおりです。

ASLR

カナリア

NXビット

GCCの最新のビルドでは、デフォルトでカナリアが適用されます。すべてのASLRが同じように作成されるわけではありません。Windows7、Linux、および*BSDには最高のASLRがいくつかあります。OSXは、ASLRの実装がはるかに最悪であり、バイパスするのは簡単です。最も高度なバッファオーバーフロー攻撃のいくつかは、エキゾチックな方法を使用してASLRをバイパスします。NXビットは、byapsを実行するのにはるかに簡単な方法であり、return-to-libcスタイルの攻撃により、エクスプロイト開発者にとって問題にはなりません。

于 2010-09-14T05:32:18.307 に答える