スタックベースのバッファオーバーフロー

Windowsにおける仮想アドレス空間のレイアウト概要を説明したので、次に、本稿のすすめかたについて念のため触れておきたい。

本稿において最初に説明していきたいのは、Windowsにおけるスタックベースのバッファオーバーフローである。よく略して「スタックオーバーフロー」と呼ぶこともある。このタイプの脆弱性が頻繁に発見されたのは遠い昔(と、いってもここ10年内の話であるが)であり、もはや主要なアプリケーションにおいては「絶滅危惧種」扱いとなっているが、その一方で、攻撃への転用性に優れてもいる。よって、まずはスタックベースのバッファオーバーフローについて本稿をまとめていきたい。

加えて、念のため記述しておくが、単に『スタックオーバーフロー』と記述した場合、通常は巨大なローカル変数を確保することや、再帰呼び出しの回数が多すぎたことに起因し、スタックに割り当て可能なメモリが不足する状態を指すことになる。よって今回は厳密に『スタックベースのバッファオーバーフロー』と記述することにしたい。

スタックの概念を理解する

次に、スタックベースのバッファオーバーフローを理解するうえで重要となるのは、プログラムの動作におけるスタック領域の利用のされ方である。それを知るためには、サブルーチンの概念ならびにスタックの概念を知らねばならない。このため、やや遠回りをしてこれらについて説明したいと思う。一点付け加えておきたいのは、本稿のテーマは"Windows"であるため、対象となるアーキテクチャはx86である。このため、x86アーキテクチャに則った解説が本稿で行われることがあることにご留意いただきたい。

さて、マシン語によるプログラミングが主流だった時代において、データを格納するために必要なメモリ領域は、コーディングの時点で用意しておく必要があった。ところが、コーディングを行う上では、一時的に小さなデータを保存する必要性に迫られることが頻繁にあった。かつては希少なリソースしかなかったため、ソフトウェアには処理の無駄を省くことで効率化を行い、機械として最大限の能力を発揮させるか、が問われていたという背景がここにはある。そのため、一時的に保存するためのメモリ領域を、コーディング時に細かく沢山確保しておくことは利用可能なメモリ量の逼迫、ひいては効率の低下につながりかねない。

そこで、ある一定の大きさのメモリ領域を確保しておき、それを「一時データ置き場」として活用することが考案された。それが、スタックである。

スタックは「皿の山」や「書籍の山」に喩えられる。ここでは書籍の山としてスタックの概念を扱うことにする。

スタックの概念(『はじめて読む8086』(蒲地輝尚)を参考に作成)

スタックはこの図版のように、あたかも「積読」状態で、床から本が積みあがるようなデータ構造をとる。以下、その概略について喩えを使いながら記す。

1. スタックは特定の基点アドレス(床)から成長する
2. 特定の基点アドレス(床)は「スタックのボトム」とも呼ばれる
3. データ(本)は最後に積み上げたデータ(本)の上のみにさらに積み上げることができる
4. 最上部のデータ(本)には目印(スタックポインタ)が付与され、「最後に載せた本」と位置づけられる
5. 積み上がった山から最初に取り出せるのは、最上部のデータ(本)である
6. データ(本)を積み上げることは[PUSH]と呼ばれ、取り出すことは[POP]と呼ばれる

このようなデータ構造は「後入れ先出し(LIFO: Last In First Out; FILO: First In Last Out)」などと呼ばれる。こうした小さなデータ用の格納場所を用意しておくことで、メモリを浪費することを抑制することを実現させた。

x86を含む複数のアーキテクチャにおいて興味深いのは、通常、データやプログラムコードはアドレス低位から高位に向かって並んでいるのに対し、スタックはアドレス高位が基点となって低位に向かって成長する点である。

ちなみに興味本位で、なぜこのようになっているのか、その理由について筆者も調べてみたが、ここやここの文献を読む限りでは、「スタック中のデータを参照する際は、(ESPなどのスタックポインタから)正方向のオフセットを指定することが自然であり、かつ利便性にも勝るため」なのだそうである。