Return-oriented programming
しかし最終的には、オペレーティングシステムは書き換え可能なメモリ空間を実行不可能にする実行保護と呼ばれる仕組みを導入し、バッファオーバーフローバグの利用への対策を実装するようになった。実行保護が有効になっていると、マシンはユーザが書き込み可能な領域のメモリにある命令の実行を拒否するようになるため、攻撃者はスタックにペイロードを書き込み、returnアドレス上書きでペイロードにjumpすることができなくなる。この後、これらの保護を強化するため、ハードウェアサポートも一般に流通するようになった。
データ実行保護により、バッファのメモリ部分は実行不可能とマークされているため、攻撃者はバッファに書き込まれた命令を直接実行することができなくなる。この保護を回避するため、Return-oriented programmingは悪意のある命令を注入するのではなく、returnアドレスを書き換えることで、実行可能なメモリ領域にすでに存在する「ガジェット」と呼ばれる命令群を利用する。攻撃者は悪意のあるコードを直接実行するのではなく、returnアドレスを書き換えることで実行可能とマークされている命令群を組み合わせて実行するため、一般的なデータ実行保護はこのような攻撃に対しては無力である。
現在流通しているデータ実行保護は、前述した従来のバッファオーバーフロー脆弱性をほぼ不可能にし、攻撃者が実行可能とマークされてすでにメモリ上に存在しているプログラムおよび共有ライブラリのコードしか実行できないようにする。libcなどの共有ライブラリは、システムコールを実行するためのサブルーチンやその他の攻撃者にとって有用な関数を含んでいるため、攻撃を組み立てるためのコードを探す上で重要となる。
return-to-library攻撃では、攻撃者は前述の手法でバッファオーバーフロー脆弱性を悪用して制御フローを乗っ取る。ただし、攻撃者はペイロードをスタックに書き込む代わりに、利用可能なライブラリの関数を選んでその最初のアドレスにreturnアドレスを上書きする。残りのスタック位置は、攻撃者が望む動作を実行するため、正しいパラメータを関数に渡すよう呼び出し規約に従って上書きされる。この手法はSolar Designerが1997年に初めて提唱し、後に無限の関数呼び出しのチェーンを可能にするよう拡張された。