ヒープとスタックのバッファオーバーフロー
スタックベースのバッファオーバーフローの脆弱性をうまく利用するには、まずバッファをオーバーフローさせて、リターンポインタを上書きし、EIPの制御を取得する必要があるというのが私の理解です。 EIPを制御したら、JMP ESP命令を使用して、スタックの先頭にジャンプし、シェルコードを実行できます（DEPまたはASLRは、単純さと理論のためだけに配置されていないと仮定しましょう）酒）。
ヒープについて、オーバーフローがまだ残っていることを理解しました。私の質問は、バッファオーバーフローの悪用はヒープ上では異なって見えますか？もしそうなら、詳細は何ですか？
スタックオーバーフローがある場合-オーバーフローし続けるだけである場合-最初にローカル変数、次に保存されたレジスター、次にアドレスを返し、次に関数の引数をオーバーフローしてから、スタックのさらに下にあるもの、おそらく例外ハンドラーなどを通常攻撃者として使用します。興味深い場所にジャンプするために返信先アドレスを上書きしました。
ヒープオーバーフローを使用すると、オーバーフローします。メモリの範囲を超えたところにあります。ヒープのメタデータである可能性のある古いまたは悪いヒープ実装では、たとえば、ものをメモリに書き込む能力（関数ポインタを上書きするために使用できます）。他のヒープ実装では、割り当てと解放のパターンを設計して、ヒープをメモリの右側に割り当てられた興味深い部分がある状態にする必要があります。多分vtableまたは他のいくつかの関数ポインター。
ヒープオーバーフローは、ヒープの実装とアプリケーションに固有のものです。 Linuxではglibc mallocが冗談（ごめんなさい！）であるため、「...の手法」の手法があります。Windowsでは、ヒープは非常に安全でランダム化されており、アプリケーションが独自の安全でないヒープ実装を持っていることを期待する必要があります。パフォーマンスが1％向上します。彼らはしばしばそうします。
実際、実行能力を獲得することが、バッファオーバーフローを悪用する唯一の方法ではありません。ハートブリードバグは、ヒープバッファオーバーフロータイプの状況の最近のよく知られた例であり、攻撃者が実行できることはすべて、バッファを超えて読み取られました。書き込みや実行能力を獲得しない。 http://heartbleed.com