クラッシュは常にRCEに悪用可能ですか？
ファジングを使用して脆弱性を探しているチームによって書かれた論文を読んで、私は多くの人々がクラッシュをDoS脆弱性として分類していることに気づきました。他の論文や研究では、クラッシュ後にさらに深くなり、それを悪用してRCEを取得しようとしています。
私の質問は、メモリに関連するすべてのクラッシュがRCEにつながる可能性があるのか、それとも特権的なものがあるのか、そしてそれらは試みさえしないのかどうかです。
多くのクラッシュは、サービス拒否（DoS）以外には何も利用できません。最も一般的な例は、NULLポインターの読み取りです。 0（またはその近く）へのポインターを逆参照しようとすると失敗し、例外/シグナルがキャッチされない限り、プログラムがクラッシュします。ただし、無効な入力が与えられたときにプログラムがゼロから読み込もうとするからといって、別の無効な入力が与えられた場合にプログラムがよりエキサイティングなことをするわけではありません。
クラッシュの悪用可能性を判断するのは難しいです。使用できるいくつかのヒューリスティックがあります（命令ポインターが非実行可能コードを指している場合、書き込みは通常読み取りよりも悪いです-NX/DEP違反-これはほぼ確実に悪用可能です、それがnullポインター読み取りである場合、それはかなりありそうにありません悪用可能）しかし、それらは完全に正確ではありません。クラッシュダンプを分析して推測を試みるツールがあります（たとえば、Microsoftは、この分析を実行するWindowsデバッガーwindbgの「！exploitable」コマンドを公開しています。Linuxデバッガーにも同様のツールがあります。 ）。確実に知るには、メモリ破損の原因となったプログラムフローを分析し、メモリフローに与える影響と、実際に危険なことを実行できるかどうかを確認する必要があります。
メモリの場所にアクセスしようとしたために発生したセグメンテーション違反を考慮してください0x0（つまり、nullポインターの逆参照）。
コードの一部が変数で行われ、ポインターをnullに設定していると考えている可能性があります。通常の操作では実際にそれが行われている可能性がありますが、ファズテストでは、何かがその変数を読み取った後に、その変数を再度読み取ろうとするEdgeケースが見つかりました。 nullに設定されました。
アプリケーションがカーネルメモリを読み取ろうとしているため、これは確かにクラッシュを引き起こし、カーネルはそのことに腹を立てますが、RCEのようなことはできません。