バッファオーバーフロー
1995年、Thomas Lopaticはそれとは独立にバッファオーバーフローを発見し、セキュリティに関するメーリングリストBugtraqへ投稿した。 1996年、エリアス・レヴィ(ハンドルネームAleph one)はオンラインマガジンPhrackで記事"Smashing the Stack for Fun and Profit"を発表した。 これはスタックベースのバッファオーバーフローを使用したエクスプロイトを手順を追って説明していく内容である。
これ以降、少なくとも2つの有名なインターネットワームがバッファオーバーフローを利用したエクスプロイトで多くのシステムに被害を与えている。2001年にはCode RedがマイクロソフトのInternet Information Services (IIS) 5.0のバッファオーバーフローを利用している。 また2003年にはSQL SlammerがMicrosoft SQL Server 2000の動作するマシンに被害を与えている。
2003年には、市販のXboxのゲームに含まれるバッファオーバーフローが利用され、無認可のソフトウェア(例えばHomebrewのゲームなど)をModチップなどのハードウェアの改造なしに動作させるのに利用された。 PlayStation 2では同じ目的のためにPS2 Independence Exploitが使用される。またWiiではHomebrewが利用されるが、これはゼルダの伝説 トワイライトプリンセスに存在するバッファオーバーフローを利用している。
今例えば、関数gはユーザから(ASCIIコードの)文字列を入力を受け取り、入力された文字列を配列char A[10]に格納するとする。Aのサイズは10であるので、関数gのプログラマはユーザから受け取った文字列をAに格納する前に、その文字列が本当に10文字以下なのかをチェックする機構をgに実装しておかねばならない。このようなチェック機構を実装するのを忘れていた場合、悪意のあるユーザ(以下、「攻撃者」と呼ぶ)によりスタックベースのバッファオーバーフロー攻撃を受けてしまう危険がある。
具体的には、攻撃者は以下のような文字列をgに入力する:
(シェルコード)...(シェルコードの仮想アドレス)
ここでシェルコードとは、何らかの悪意のある短いプログラムで、例えば攻撃者のためにバックドアを開けたり、マルウェアのダウンロードを行ったりする。
この文字列が配列Aの先頭から順に書き込まれていくと、A[i]のアドレスはiが大きいほど大きくなるので、攻撃者が入力文字列の長さを適切に選べば、アドレス空間には以下のようにデータが書き込まれ、gのリターンアドレスがシェルコードの仮想アドレスに上書きされる:
よって関数gが終了したとき、gのリターンアドレス(の箇所に上書きされたシェルコードの仮想アドレス)が読み込まれるので、プログラムカウンタはシェルコードの位置にジャンプし、攻撃者の狙い通り、シェルコードが実行される事になる。
標準Cライブラリを使う代わりに、バッファあふれを未然に防いだりエラーとして検出してくれたりするセキュアなライブラリを使う事も重要である。このようなライブラリとして以下のようなものがある。
Managed String(Linux環境)
ISO/IEC 9899:2011 Annex K(Windows環境)
SafeStr(Linux環境、Windows環境)
"The Better String Library"
Vstr
Erwin
またBSD libcなど、Cライブラリの実装によってはstrlcpyやstrlcatといった、より安全に配慮した文字列用関数が用意されている。