web-dev-qa-db-ja.com

CVE評価の解釈:バッファオーバーフローvs.サービス拒否vs.リモートコード実行(RCE)

CVEにバッファオーバーフローの脆弱性がリストされているが、リモートコード実行はリストされていない場合、それを次のように解釈する必要があります。

  1. この脆弱性は、RCEを公開することが確認されていません。
  2. この脆弱性は、RCEを公開しないことが確認されています。
  3. 誰か(誰?)は、おそらくRCEを公開していないと考えています。

または、他の何か?この情報は一般的に信頼できますか?

編集:最初の検出後にRCEの脆弱性を確認することは、非常に困難で時間がかかる可能性があります。研究者は、最初に曝露の全範囲を確認せずにセグメンテーション違反を報告することがあると思います。それが私をこの質問に導きました。

1
jtpereyda

これをそのように解釈する必要があります。信頼できない入力は、アプリケーションがそのサイズをチェックできないために、書き込むはずのないメモリ内のセクションに書き込むことができます。

まったく別の問題になる可能性がある場合は、常にRCEをバッファオーバーフローの拡張として分類するという考え方になっていると思います。たとえば、リモートファイルインクルードによるRCEや、スクリプト言語でevalを利用するWebアプリケーションの欠陥、または信頼できない入力を使用してOSコマンドを実行する場合を考えてみましょう。これらはRCEですが、必ずしもBOFである必要はありません。

私が言っているのは、バッファオーバーフローは、脆弱性とは何か、そしてそれがどのように発生するかを説明する独自のカテゴリとして扱うことができるということだと思います。 RCEまたはDoSに拡張される可能性がありますが、オーバーフローを理解するには完全です。

オーバーフローの脆弱性が見つかった場合は、関連する公開されたエクスプロイトコードをいつでも確認し、それについて詳しく読んで、DoSまたはRCEが存在するかどうかを確認できます。ほとんどの(すべてではないにしても)BOFは、少なくともすでにDoSです。また、オーバーフローがRCEにつながることを読み取ることは可能ですが、パブリックエクスプロイトを見つけることはできません。これは、特にプロプライエタリなソフトウェアでは一般的です。これは、それが未確認であることを意味するのではなく、研究者が決して一般に公開されておらず、独自のセキュリティツールの一部である可能性があることを意味します。

1
Link