セキュリティに関する最初の CS レクチャーの 1 つで、疑惑のバッファ長をチェックしないという C の問題と、この脆弱性が悪用されるさまざまな方法の例について説明しました。
この場合、悪意のある読み取り操作のケースのように見えます。アプリケーションがメモリのバイト数を読み取っただけです。
Heartbleed バグは C バッファの長さチェックの問題の現れであると主張するのは正しいですか?
別のアプリケーションのメモリを読み取ろうとしたときに、悪意のある使用によってセグメンテーション違反が発生しなかったのはなぜですか?
メモリに書き込む前にメモリをゼロにするだけで（その後メモリから読み取ると）、セグメンテーション違反が発生しますか？または、これはオペレーティング システムによって異なりますか? それとも、他の環境要因の間ですか？
どうやらバグの悪用は特定できません。これは、呼び出されたときにハートビート関数がログに記録されないためですか? そうでなければ、〜64k文字列に対するリクエストは悪意がある可能性が高いですか?
Heartbleed バグが C バッファ長チェックの問題の現れであると断言するのは正しいですか?
はい。
ハートブリード バグは、C の古典的なバッファ オーバーフロー エクスプロイトの現れですか?
いいえ。「従来の」バッファ オーバーフローは、スタックに割り当てられたバッファに保持できるよりも多くのデータを書き込むもので、書き込まれたデータは敵対的なエージェントによって提供されます。敵対的なデータはバッファをオーバーフローさせ、現在のメソッドの戻りアドレスを上書きします。メソッドが終了すると、攻撃者が選択したコードを含むアドレスに戻り、実行を開始します。
対照的に、ハートブリードの欠陥はバッファを上書きせず、任意のコードを実行せず、メモリ内の近くに機密データが存在する可能性が非常に高いコードの範囲外を読み取るだけです。
別のアプリケーションのメモリを読み取ろうとしたときに、悪意のある使用によってセグメンテーション違反が発生しなかったのはなぜですか?
別のアプリケーションのメモリを読み取ろうとしませんでした。エクスプロイトは、別のプロセスではなく、現在のプロセスのメモリを読み取ります。
悪意のある使用により、バッファの範囲外でメモリを読み取ろうとしたときにセグメンテーション違反が発生しなかったのはなぜですか?
これはこの質問の複製です：
セグメンテーション違反は、オペレーティング システムのメモリ マネージャーが割り当てていないページにアクセスしたことを意味します。ここでのバグは、ヒープ マネージャーが割り当てていない有効なページのデータにアクセスしたことです。ページが有効である限り、segfault は発生しません。通常、ヒープ マネージャーは OS に大量のメモリを要求し、それをさまざまな割り当てに分割します。これらの割り当てはすべて、オペレーティング システムに関する限り、メモリの有効なページ上にあります。
null の逆参照は、オペレーティング システムがゼロ ポインターを含むページを有効なページにしないため、単純にセグメンテーション違反です。
より一般的には、コンパイラとランタイムは、未定義の動作がセグメンテーション違反になることを保証する必要はありません。UB はあらゆる動作を引き起こす可能性があり、それには何もしないことも含まれます。この問題に関するその他の考えについては、以下を参照してください。
UBは常にセキュリティ クリティカルなコードの segfault と同等であるべきであるという私の不満と、脆弱性の静的分析に関する議論へのいくつかのポインタについては、今日のブログ記事を参照してください。
http://ericlippert.com/2014/04/15/heartbleed-and-static-analysis/
メモリに書き込む前にメモリをゼロにするだけで（その後メモリから読み取ると）、セグメンテーション違反が発生しますか？
ありそうもない。範囲外の読み取りでセグメンテーション違反が発生しない場合、範囲外の書き込みで発生する可能性はほとんどありません。メモリのページが読み取り専用である可能性はありますが、この場合はありそうにありません。
もちろん、後ですべきではないあらゆる種類のメモリをゼロにすることの結果は、ショー全体のセグ フォールトです。後で逆参照するゼロ化されたメモリにポインターがある場合、それは null を逆参照しているため、セグメンテーション違反が発生します。
これはオペレーティング システム間で異なりますか?
質問があいまいです。言い換えさせてください。
オペレーティング システムや C/C++ ランタイム ライブラリが異なれば、仮想メモリの割り当て、ヒープ メモリの割り当て、およびメモリ アクセスが範囲外になったときの識別について、異なる戦略が提供されますか?
はい; 異なるものは異なります。
それとも、他の環境要因の間ですか？
そのような？
どうやらバグの悪用は特定できません。これは、呼び出されたときにハートビート関数がログに記録されないためですか?
正しい。
〜64k文字列に対するリクエストは、悪意がある可能性が高いですか?
私はあなたの思考の流れに従っていません。要求が悪意のあるものである可能性が高いのは、送信されたバイトとエコーが要求されたバイトとの間の不一致であり、エコーが要求されたデータのサイズではありません。
アクセスされるデータは要求されたデータのすぐ隣にあり、通常は同じプロセスのメモリ内にあるため、セグメンテーション違反は発生しません。リクエストが十分に大きい場合は例外が発生する可能性がありますが、プロセスをクラッシュさせるとデータを取得できなくなるため、それを行うことは悪用者の利益にはなりません。
明確な説明については、このXKCDコミックをご覧ください。
