バッファオーバーフローの脆弱性は常にコード実行の脆弱性を意味しますか？
バッファオーバーフローにより、悪意のあるハッカーは常にバッファの外に書き込み、悪意のあるハッカーが配置できるシェルコードへのリターンポインタを上書きできるので、スタックバッファオーバーフローの悪用が成功した場合、常に正しい方法でシェルを呼び出すことができます。 ？少なくとも理論的には、DEPとASLRが配置されていないと想定する場合。
いいえ、バッファオーバーフローは次のようになります。
- スタックではなく、ヒープ上のバッファに反対してください。これは依然としてコードの実行につながる可能性がありますが、悪用するにははるかに複雑になります。
- サイズが制限されているため、戻りポインタを上書きできません。 （例：バッファを超えて1バイトしか書き込めない）
- どのバイトを書き込むことができるかを制限して、適切なポインターが書き込まれないようにします。
- スタックCookieを上書きします。これは、戻りアドレスが使用される前に検出されます。 Cookieが漏洩しない限り、エクスプロイトはコードの実行につながるのではなく、ほとんどの場合プロセスをクラッシュさせます。
- 上向きに成長するスタックにいるので、戻りアドレスを上書きできません。エクスプロイトは、他のローカル変数を上書きできる可能性があります。または、バッファーが別の関数に渡される可能性がありますが、コードの実行は下向きのスタックほど信頼性が高くありません。
これらの一部は依然としてコード実行につながる可能性がありますが、他のインスタンスは悪用することが不可能である可能性があります。
ただし、バッファオーバーフローが発生している場所を見つけたら、通常、悪用できないことを証明するよりもはるか修正する方が簡単です。
ダグラスは正しい答えを出します。すべてのバッファオーバーフローでコードが実行されるわけではありません。しかし、非常に重要な注意が欠けていると感じました。
バッファオーバーフローによって任意のコードが実行できない場合でも、安全であるとは限りません。
書き込みバッファオーバーフローにより、想定外のデータに書き込むことができます。関数アドレスであるそのデータは、特別なケースです。たとえば、名前と権限のフィールドを持つユーザー構造体があるとします。私の名前を「JosiahhasaverylongnameAdmin」に設定すると、任意のコードを実行せずに深刻な脆弱性を悪用する方法を想像するのは簡単です。
別の実例として、ハートブリードを覚えているとしたら、それはバッファオーバーフローです。これは、書き込みオーバーフローではなく、単なる読み取りオーバーフローです。そこでコードが実行される可能性はありませんが、機密性に壊滅的な侵害があったとしても。
簡単な答えは「いいえ」です。すべてのバッファオーバーフローがコードの実行につながるとは限りません。オーバーフローは小さすぎて必要なポインター/値を上書きできない、オーバーフロー部分を制御して物事を上書きできない、または多すぎてスタックCookie /カナリアなどを強制終了する可能性があります。