PacSec2017

1. メモリ不足からリモートコード実行
Yuki Chen (@guhe120)
Qihoo 360Vulcan Team

2. CVE-2014-0290,CVE-2014-0321,CVE-2014-1753,CVE-2014-1769,CVE-2014-1782,CVE-2014-1804,
CVE-2014-2768,CVE-2014-2802,CVE-2014-2803,CVE-2014-2824,CVE-2014-4057,CVE-2014-4092,
CVE-2014-4091,CVE-2014-4095,CVE-2014-4096,CVE-2014-4097,CVE-2014-4082,CVE-2014-4105,
CVE-2014-4129,CVE-2014-6369,CVE-2015-0029,CVE-2015-1745,CVE-2015-1743,CVE-2015-3134,
CVE-2015-3135,CVE-2015-4431,CVE-2015-5552,CVE-2015-5553,CVE-2015-5559,CVE-2015-6682,
CVE-2015-7635,CVE-2015-7636,CVE-2015-7637,CVE-2015-7638,CVE-2015-7639,CVE-2015-7640,
CVE-2015-7641,CVE-2015-7642,CVE-2015-7643,CVE-2015-8454,CVE-2015-8059,CVE-2015-8058,
CVE-2015-8055,CVE-2015-8057,CVE-2015-8056,CVE-2015-8061,CVE-2015-8067,CVE-2015-8066,
CVE-2015-8062,CVE-2015-8068,CVE-2015-8064,CVE-2015-8065,CVE-2015-8063,CVE-2015-8405,
CVE-2015-8404,CVE-2015-8402,CVE-2015-8403,CVE-2015-8071,CVE-2015-8401,CVE-2015-8406,
CVE-2015-8069,CVE-2015-8070,CVE-2015-8440,CVE-2015-8409,CVE-2015-8047,CVE-2015-8455,
CVE-2015-8045,CVE-2015-8441,CVE-2016-0980,CVE-2016-1015,CVE-2016-1016,CVE-2016-1017,
CVE-2016-4120,CVE-2016-4160,CVE-2016-4161,CVE-2016-4162,CVE-2016-4163,CVE-2016-4185
CVE-2016-4249,CVE-2016-4180,CVE-2016-4181,CVE-2016-4183,CVE-2016-4184,CVE-2016-4185,
CVE-2016-4186,CVE-2016-4187,CVE-2016-4233,CVE-2016-4234,CVE-2016-4235,CVE-2016-4236,
CVE-2016-4237,CVE-2016-4238,CVE-2016-4239,CVE-2016-4240,CVE-2016-4241,CVE-2016-4242,
CVE-2016-4243,CVE-2016-4244,CVE-2016-4245,CVE-2016-4246,CVE-2016-4182,CVE-2016-3375,
CVE-2017-3001,CVE-2017-3002,CVE-2017-3003,CVE-2017-0238,CVE-2017-0236,CVE-2017-8549,
CVE-2017-8619
自己紹介
バウンティハンター @ 360 Vulcan Team

3. 自己紹介
ハードコアな
アニメ漫画ゲーム
オタク

4. 360Vulcan Teamについて
ü Qihu 360の
セキュリティリサーチャー
ü Pwn2Ownの実績:
ü Pwn2Own 2015 IE11
ü Pwn2Own 2016 Google
Chrome, Adobe Flash
ü Pwn2Own 2017 Edge, Safari,
Adobe Flash, Win10, Mac OSX
ü “Master of Pwn” Pwn2Own
2017

5. アジェンダ
• ブラウザのメモリ不足(OOM)例外
• メモリ不足からリモートコード実行(RCE)
• メモリ不足からASLRのバイパス
• まとめ

6. Webブラウザの
メモリ不足(OOM)例外

7. メモリ不足(Out of memory)例外
“十分なメモリが無い場合に発生する
ランタイム例外”

8. ブラウザOOMの例 1
• IE 8 CAZrArrayの解放済みメモリの使用(use-a[er-free) (cve-2014-1753)
• ファジングにより発見
function f() {
var size = 0x8000000;
var s = "AAAA";
while (s.length < (size - 2)/2)
s += s;
var x = document.createElement("frame");
x.setAttribute("prop2", s.substring(0, (size - 2)/2));
var node = document.body.appendChild(x);
for ( var y = 0; y < 20; ++ y ) {
var z = node.cloneNode();
document.body.appendChild(z);
}
}

9. CloneNode
属性を
ひとつずつ
複製
新しい
属性配列の
作成
属性
複製
失敗?
属性配列
の解放
属性配列に
アクセス
(UAF： use-
a[er-free)
コピーする属性が非常に大きい文字列である場合、
その属性を複製するとメモリ不足を発生させることができる。
最終的に、解放済みメモリの使用(use-a+er-free)が発生する

10. ブラウザOOMの例 2
• IE Jscirpt JSON.parse OOMメモリ破損
var chunksize = 0x2000000;
var json = '['
for ( var i = 0; i < chunksize/0x10; ++ i )
json += '1,'
json += '1]';
var arr = new Array();
try {
for ( var i = 0; i < 0x1000; ++ i )
arr.push(json.substr(0, (chunksize-2)/2));
} catch (e) {} //大量のメモリを割り当てることにより
IEを低メモリ状態に強制する
while (true) {
JSON.parse(json);
}

11. jscript!JSONParser::ParseObject+0x3fb:
65b4e9da mov eax,dword ptr [esi+14h] // length of the json array
65b4e9dd mov dword ptr [esp+14h],eax
65b4e9e1 shl eax,4 // alloc size = arr_length * 0x10
65b4e9e4 push eax
65b4e9e5 mov dword ptr [esp+20h],eax
65b4e9e9 call dword ptr [jscript!_imp__malloc (65b740fc)]
// もしメモリが十分でない場合、mallocを失敗できる
// mallocの失敗をチェックしていないかコンテンツを直接アドレスにコピーする
[NULL + arr_size]
65b4ea2f a5 movs dword ptr es:[edi],dword ptr [esi] es:002b:00777fc0=????????
ds:002b:03eb8398=00000003

12. OOMバグ – 異なるタイプ
• 対処済み/未対処
• 制御可能/制御不可能
• 32ビット/64ビット
• 継続可能/継続不可能

13. 対処済み/対処無し
• 対処されたOOM
– 開発者はコード内にOMMの可能性を意識している
– しかし正しく対処されていない (例えば、IE CAZrArray
UAFのケース)
• 対処されていないOOM
– 開発者はコード内にOMMの可能性を意識しておらず
ノーアイデア (例えば、JSONのケース)
– 予期しない実行パスの変更（アーリーリターン、例外）
を引き起こし、悪用可能な状態を引き起こすことがで
きる

14. 制御可能/制御不可能
• 制御可能
– いつでもOOMの例外を確実に発生できる場合
• 大きな割り当て(large allocadon)の制御
• 低メモリ(low-memory)状態の制御
• 制御不可能
– ランダムに発生するため制御できない場合
• 小さな割り当て(Small allocadons)
• 制御できない低メモリ(low-memory)状態

15. 32ビット/64ビット
• 通常、信頼性の高いOOMを見つけるのは64
ビットよりも32ビットをターゲットにする方が簡
単
• 32ビットのターゲットに対して、プロセスを強
制的に低メモリ状態にする方が簡単だから
– ブルートフォースアロケーションを使う

16. 継続可能/継続不可能
• 継続可能
– プログラムがOOMの後も実行を継続できる場合
– エクスプロイト可能
• 継続不可能
– プログラムがOOMの後に実行を継続できない場合
• 悪用できないメモリ破損のために即クラッシュしてしまう (例えば、
nullポインタデリファレンス)
• 失敗しない割り当てでもクラッシュしてしまう
• ブラウザのメモリ制限により、メモリの制限を超えた場合にクラッ
シュしてしまう
– エクスプロイトできない、DOSのみ L

17. 制御可能または継続可能な
OOM例外のみ見つける/
フォーカスすること
バグハンターへ:

18. OOMのバグの探し方
• 普通のファジング
– ランダム値によるファジングで時々OOMが発生する
ことがある
• 低メモリ状態のファジング
– Applicadon Verifierのようなツール
– アロケーションAPIのフック
– 一部のブラウザにはメモリ不足のシミュレーション用
のテストインターフェースがある (例えば、FireFox)
• コードの監査

19. メモリ不足(OOM)から
リモートコード実行(RCE)

20. Microso[ EdgeのOOMバグを発見す
るまで
• Edgeの制御可能なOOMを見つける
• 不整合な配列の状態を作るためにトランザク
ション処理をブレイクする
• メモリ破損状態を作り出す
• 成功

21. Edgeの制御可能なOOMを見つける
• OOM例外を確実に発生させる必要がある
• JavaScript配列セグメントの割り当ては良い
着眼点

22. 配列セグメント
• IE/EdgeのJavaScript配列
– 配列セグメントのリンクリスト
長さ
ヘッド
配列
ヘッドセグメント
レフト(le[)
長さ(length)
サイズ(size)
次の位置(next)
要素(element)[0]
要素(element) [N]
…
セグメント 1
レフト(le[)
長さ(length)
サイズ(size)
次の位置(next)
要素(element) [0]
要素(element) [N]
…
セグメント
N…

23. var arr = new Array();
arr[0] = 1;
arr[1] = 2;
arr[2000] = 3;
arr[5000] = 4;
ヘッド
セグメント
arr
le# = 0
length = 2
element[0] = 1
element[1] = 2
セグメント
1
セグメント
2
le# = 2000
length = 1
element[0] = 3
le# = 5000
length = 1
element[0] = 4

24. 配列セグメント(.cont)
• JavaScript配列の要素はセグメントに格納され
る
– 配列セグメントを割り当てるときに、配列内の要
素にメモリ空間が割り当てられる
• 新しい要素を配列に追加するときに既存の領
域が無い場合は、新しいセグメントを割り当て
るか既存のセグメントを拡大する

25. 32ビット版Edgedでの配列セグメントの
割り当てによるOOM
• 配列セグメントを割り当てるとき、十分なメモリが無い場合
は、OOM例外をスローする

26. try {
for (var i = 0x10000000; i < 0x18000000; ++ i)
a[i] = 0x0d0d0d0d;
} catch (e) {}
try {
while (true) {
arr_ab.push(new ArrayBuffer(0x02c9dbec * 4)); // Step 1:大容量
のメモリを割り当てることにより、ブラウザを低メモリ状態にする
}
} catch (e){}
try {
a.reverse(); // Step 2: 配列セグメントの割り当てによって
OMM例外をスローする
} catch (e) {alert(e);}
32ビット版EdgeでのOOMの発生 – 例

27. 32ビット版EdgeでのOOMの発生
– 例 (.cont)

28. 64ビット版Edgeでの配列セグメントの
割り当てによるOOM
• 64ビット版Edgeを強制的にメモリ不足にするこ
とはできない
– 64ビットプロセスのメモリ空間が大きいため
• 64ビット版EdgeでOOM例外を発生させるチャ
ンスはまだ残っている
– もしアロケーションサイズがオーバーフローした
場合

29. アロケーションサイズオーバーフロー時のOOM

30. Var aaa = new Array();
For (var I = 0; I < arrSize.length; ++ i) {
aaa.unshi[.apply(aaa, args); // Step 1: 大体オーバーフローするまで
配列セグメントのサイズを大きくする
aaa[arrSize[i] – 1] = 1;
}
try {
aaa.unshi[.apply(aaa, args); // Step 2:サイズがオーバーフローしそう
な場所で別のセグメントサイズを増やす
} catch (e) { // Error: Out of Memory }
64ビット版EdgeでのOOMの発生 – 例

31. 64ビット版EdgeでのOOMの発生
– 例 (.cont)

32. これで32ビット/64ビット版のEdgeで
制御可能なOOMができた。次は？

33. 配列トランザクションの操作
• 配列にはいくつかのインポートフィールドがある
– 配列: 配列タイプ、長さ、ヘッド、キャッシュされた最後
に使われたセグメント
– セグメント: レフト、長さ、サイズ、要素
• フィールドの1つを変更する場合、配列を有効に
保つため他のフィールドも変更する必要がある
– 例えば、int配列をfloat配列に変換するとき、セグメン
トのint要素もfloatに変更する必要がある

34. 配列トランザクション操作(.cont)
• 多くのJavaScript配列のAPIは配列を変更する
– shi[、unshi[、splice …
– そのようなコードのコア部分では原子性と一貫性
が求められる
– データベースのトランザクションと同じように、配
列トランザクション操作と呼んでいる
– 配列トランザクション操作の中断は問題を引き起
こすことができる

35. 配列トランザクション操作 – 例
• NadveInt配列からNadveFloat配列への変換
配列内のForeachセグメント :
segment->ChangeElementsToFloat()
SetArrayType(NaCveFloatArray)
もし繰り返しの途中でコードが予期せず返ってきた場合、
いくつかのFloatセグメントを持つNaHveIntArrayを取得する

36. 配列トランザクション操作の中断
• トランザクション操作のコールバック
– Edgeのバグの共通パターン
• コードのフローを中断する例外
– メモリ不足(OOM)例外J

37. レッツ パーティ！

38. リモートコード実行のケース: Array.unshi[
nElemntsToUnshiG = UnshiGする要素の数
配列のForeachセグメント:
segment->leG += nElemntsToUnshiG (1)
SetUnshiGElementsToHeadSegment(); (2)
Array->length += nElemntsToUnshiG; (3)
Array.unshi[のトランザクション操作

39. nElemntsToUnshiG = UnshiGする要素の数
配列のForeachセグメント:
segment->leG += nElemntsToUnshiG (1)
SetUnshiGElementsToHeadSegment(); (2)
Array->length += nElemntsToUnshiG; (3)
中断
要素をヘッドセグメントに設定すると、
ヘッドセグメントの再割り当てが発生し、
メモリ不足例外をスローすることができる

40. リモートコード実行のケース: Array.unshi[
• Array.unshi[トランザクション操作を中断する
ことで
– 一貫性の無い配列ができる:
array->lastSegment->le[ + array->lastSegment->length
> array->length
– 配列の操作コードと思い込ませる:
array->lastSegment->le[ + array->lastSegment->length
<= array->length

41. リモートコード実行 Case: Array.unshi[
• 一貫性のない配列に対してArray.unshi[を再
度呼び出す:
arr->lastSegment->length > arr->lastSegment->size
• 長さがサイズよりも大きい配列セグメントは、
さまざまな場所でヒープオーバーフローを引
き起こすことができる
– JavaScriptArray::DirectSetElementAtとか

42. リモートコード実行のケース: Array.unshi[
• 配列セグメントのヒープオーバーフローは比
較的簡単にエクスプロイトできる
• オーバーフローされるセグメントの後に別の
配列セグメントを割り当てるだけで、次のセグ
メントの長さとサイズを上書きすることができ
る
レフト 長さ サイズ
オーバーフロー
0xffffffff 0xffffffff
オーバーフロー
されるセグメント
次の
セグメント

43. リモートコード実行のケース: Array.unshi[
• Pwn2Own 2017でEdgeを攻略するために使用
• CVE-2017-0238として修正
デモ

44. リモートコード実行のケース:
JavascriptNadveIntArray::ToNadveFloatArray
• この関数は、int配列をfloat配列に変換する
配列のForeachセグメント:
seg->size >>= 1 (1)
if (seg->length > (seg->size >>= 1))
seg = AllocateNewSegment (2)
Seg->ChangeElementToFloat() (3)
Adjust(seg->length) (4)
JavascriptNadveIntArray::ToNadveFloatArrayのトランザクション操作

45. 配列のForeachセグメント:
seg->size >>= 1 (1)
if (seg->length > (seg->size >>= 1))
seg = AllocateNewSegment (2)
Seg->ChangeElementToFloat() (3)
Adjust(seg->length) (4)
中断
新しい配列セグメントを割り当てると、
メモリ不足例外(OOM)をスローすることができる。
この時点で、seg-> sizeは2で除算されるが、
seg-> lengthは変更されない

46. • ToNadveFloatArrayトランザクション操作を中断するこ
とで
– 配列セグメントができる
Seg->length > Seg->size
• Array.unshi[と同じような方法でリモートコード実行が
できる
– 2017年3月のPwn2Own 2017に挑んだときに予備として
持っていたバグの一つ
– 我々はバックアップとして複数の同じようなバグを準備し
ていた (例えば、 Array.splice)
リモートコード実行のケース:
JavascriptNadveIntArray::ToNadveFloatArray

47. パッチの時間 – 4月修正
• このPwn2OwnのバグをMicroso[は4月に修
正
• この修正に少し驚いた
– OOMの例外は修正されていなかった
– 代わりに我々が使ったエクスプロイトテクニックを
防ごうとしていた
• 新しい関数 “CheckLengthVsSize”の追加
• “segment->length > segment->size”によって引き起こさ
れるヒープオーバーフローを回避するため

48. CheckLengthVsSize
もし “segment->length > segment->size”を検出
した場合、すぐにプロセスをクラッシュさせる

49. この4月の修正の問題
• これにより我々のいくつかのOOMのエクスプ
ロイトを防ぐことができる
• しかし根本原因はまだ修正されていない
– 根本原因: OOM例外は配列トランザクション操作
を中断させる
• また、他のOOMの脆弱性は、 “seg-> length>
seg-> size”を悪用する必要が無い

50. パーティーを続けよう
OOMのバグであと10か月は戦える
OOMバグはあと１０ヶ月は戦える！

51. リモートコード実行のケース:
Array.reverseセグメント
解放済みメモリの使用(Use A[er Free)
セグメントリスト全体を反転させる (1)
ヘッドがリーフセグメントであれば:
head = ReallocateNonLeafSegment (2)
Array.reverseのトランザクション操作

52. リーフセグメント
• リーフセグメント
– 純粋なデータセグメント
– GCの次のセグメントはスキャンされない
• 非リーフセグメント
– GCの次のセグメントはスキャンされる
非リーフ 非リーフ リーフ
リーフ 非リーフ 非リーフ
ü
X最後の2つのセグメントはGCによって
スキャンされずに予期せず解放されて、
use a[er freeの原因となる

53. リモートコード実行のケース:
Array.reverseセグメント
解放済みメモリの使用(Use A[er Free)
非リーフ
Step 1: セグメントリストを逆転する
Step 2: リーフセグメントの場合は
ヘッドを再割り当て
非リーフ リーフ
リーフ 非リーフ 非リーフ
非リーフ 非リーフ 非リーフ
中断
非リーフセグメントを再割り当てすると、メモリ不足(OOM)の
例外を引き起こす

54. リモートコード実行のケース:
Array.reverseセグメント
解放済みメモリの使用(Use A[er Free)
• Array.reverseのトランザクション操作の中断に
より、 すでに解放されている配列セグメント
にアクセスできる
• 完全なリモートコード実行が簡単にできる
– 配列セグメントの解放されたメモリを再利用
– 偽の配列セグメントを取得 (OOMへのアクセスの
実現、型の取り違え、 …)

55. リモートコード実行のケース:
Array.reverseセグメント
解放済みメモリの使用(Use A[er Free)
• 6月のCPUでCVE-2017-8549として修正
• Edgeのバグバウンティで$15,000ゲット
– Microso[に感謝 J

56. リモートコード実行のケース:
ConvertToVarArray
バッファオーバーフロー
• JavascriptNadveFloatArray::ConvertToVarArra
y のバッファオーバーフロー
配列のForeachセグメント:
segがリーフセグメントであれば:
seg = ReallocateNonLeafSegment() (1)
seg->size *= 2 (2)
seg>ChangeIntElementsToVar() (3)
Array->ChangeTypeToVarArray() (4)

57. Seg->size *= 2 ?
• 32ビット版Edge、sizeof(Var) = 4, sizeof(Float) = 8
• したがって、floatセグメントをvarセグメントに変換
する場合、セグメントの容量（サイズ）を2倍にす
ることができる
Float Float
var var var var

58. 配列のForeachセグメント:
segがリーフセグメントであれば:
seg = ReallocateNonLeafSegment() (1)
seg->size *= 2 (2)
seg>ChangeIntElementsToVar() (3)
Array->ChangeTypeToVarArray() (4)
中断
非リーフセグメントを再割り当てすると、メモリ不足の
例外(OOM)が発生することがある。繰り返しの途中
（1）で壊れた場合、一部のセグメントのサイズは倍に
なっているが、倍になったサイズは元に戻されない

59. リモートコード実行の場合:
ConvertToVarArrayの型の取り違え
• JavascriptNadveFloatArray::ConvertToVarArra
yのトランザクション操作の中断により
– いくつかの倍のサイズのセグメントを持つfloatの
配列ができる
• セグメントの境界を直接読み書きできる
– あとはエクスプロイトを完成させるだけ

60. パッチの時間 (再び)
• ようやくMicroso[は根本原因の修正を開始
– おそらく、我々がPwn2Ownの後もOOMのバグを
報告し続けたからだろう
• 修正内容
– 特定の関数でOOMの例外を検出した場合にプロ
セスをクラッシュさせる

61. AutoDisableInterrupt
• コード領域を保護するためのクラス
• 保護されたコード領域で例外をスローされる
とプロセスをクラッシュさせる
• 根本原因は解決
– unshi[、splice、配列変換などの多くのインポート
機能が追加された …
– たぶん、いくつかの関数を忘れてる？

62. リモートコード実行のケース:
Array.reverse (再び)
• AutoDisableInterruptのパッチの後も
– Array.reverseは保護されなかった
• CVE-2017-8619でOOMセグメントUAFの問題
は修正されたと報告
• その後、別のOOMの問題を同じ関数で発見
– CVE-2017-8753
– 無効なlastUsedSegmentによって型の取り違えを
引き起こされる

63. lastUsedSegment
• JavaScript配列は最後に使用された配列セグ
メントをキャッシュし、配列アクセスのスピード
アップをしている
• したがって、セグメントが配列から削除される
と、lastUsedSegmentも更新される必要がある。
そうでない場合、問題が引き起こされる

64. リモートコード実行のケース:
Array.reverse (再び)
lastUsedSegment = head; (1)
head = AllocateNewHead(); (2)
最後のセグメントがリーフでない場合:
ReallocateLastSegmentToNonLeaf(); (3)
lastUsedSegment = head; (4)
中断
非リーフセグメントを再割り当てすると、メモリ不足(OOM)
の例外が発生することがある。もし(3)で中断した場合、
lastUsedSegmentは無効なセグメントを指している

65. 無効なlastUsedSegmentの悪用
• このようなバグの悪用方法について我々の
チームメンバ@LiuLongに感謝
• 悪用方法
– 配列の型を変更 (例えば、int配列 -> float配列)
– 配列の型の変更ではlastUsedSegmentは更新さ
れない
– その後でlastUsedSegmentの要素にアクセスする
と、型の取り違えができる

66. まだ終わらない …
• CVE-2017-8753が9月に修正
• EdgeのOOMの悪用は終わり？
• さあ確認してみようJ
• たぶん、デモの時間

67. メモリ不足(OOM)から
ASLRのバイパス

68. 64ビット版Edgeのメモリを使い切る？
• 通常はできない
– メモリを使い切る前にブラウザ (およびシステム
全体) が遅くなったりフリーズする
– あまりにも多くのメモリをコミットしてしまうため
• 64ビットブラウザの興味深い機能が見つから
ない限り

69. 高速配列バッファ
• 64ビット版Edgeでは、サイズが0x10000 (64
KB)より大きい配列バッファを割り当てると、そ
れは “高速配列バッファ(fast array buffer)”と
なる
– ab = new ArrayBuffer(0x10000); // 仮想の配列
バッファを作成
• Edgeは高速配列バッファごとに0x100000000
(4GB)バイトを予約する

70. バッファごとに4GB？

71. どういう意味か
• 64KBの高速配列バッファが割り当てられたと
き、実際にコミットされるメモリサイズは64KB
• しかし、Edgeは4GBの仮想メモリ空間を確保
する
• したがって、64KBのメモリをコミットするだけで
4GBのメモリを占有することができる

72. 64KBのコミット、4GBの確保

73. 64ビット版Edgeの
ユーザーモードのメモリ空間
• Windows 10はユーザーモードのメモリとして
48ビットを使用
• ユーザーヒープアドレスは常に
0x800000000000以下
• したがって、ユーザーモードのメモリ空間を使
い切るには、0x8000未満の配列バッファをス
プレーする必要がある

74. 64ビット版Edgeの
メモリを使い切るための5行
var arr = new Array(0x10000 / 2);
try {
for (i = 0; i < arr.length; i ++ )
arr[i] = new ArrayBuffer(0x10000);
} catch (e) { // out of memory excepdon}

75. スプレーの最後に
rcx=0000000800000000
rcx=0000000700000000
rcx=0000000600000000
rcx=0000000500000000
rcx=0000000400000000
rcx=0000000300000000
rcx=0000000200000000
rcx=0000000100000000
驚いたことに、ほとんどの配列バッファのスプレーが
終わると、予測可能なアドレスにメモリを割り当てはじ
める

76. 固定のアドレスで固定のコンテンツを取得
• スプレーが終了した後、高速配列バッファの1
つが固定のアドレス (例えば、0x200000000)
に割り当てられる
• その配列バッファを解放して、興味深いオブ
ジェクト (例えば、JavaScript配列)をスプレーす
ると、これらのオブジェクトがその固定のアド
レスに割り当てられることが分かり、我々は
ASLRをバイパスすることができた

77. 0x10000000
0x20000000
0x30000000
…
高速配列バッファ
高速配列バッファ
高速配列バッファ
高速配列バッファ
高速配列バッファ
0
オブジェクトのスプレー

78. デモ

79. 効果
• 64ビット版Edgeで、制御できるコンテンツを制
御できるアドレスに配置できる
• 特定のバグの悪用を容易にする
– 任意の場所への書き込み(Write-to-any once)
– 解放済みメモリの使用(Use a[er free)
– 型の取り違え(Type confusion)

80. 制限
• スプレー終了までに時間がかかる
– ～300秒、私のラップトップでは
• 実際の攻撃には適していない
• Pwn2Ownのようなコンテストで使うには良い
オプションJ

81. ASLRのバイパスの先に
• 64ビットのメモリ空間を使い切った後に、32
ビットプロセスと同様に制御可能なOOMがで
きる
• 32ビットプロセスのみで悪用可能なOOMの脆
弱性は、この問題と組み合わせると64ビット
でも悪用できる

82. まとめ
• ブラウザのメモリ不足(Out-of-Memory)の例
外は、よく 開発者/バグハンターから無視さ
れていた
• 最新のブラウザで制御可能なものに焦点を
当てれば、悪用可能なものを見つけることは
まだ可能
• OOMの問題を真剣に受け止める必要がある

83. ありがとうございました！