shockwave のブラックボックス的監査 aaron portnoy and logan brown, tippingpoint dvlabs...

Shockwave のブラックボックス的監査

Aaron Portnoy and Logan Brown, TippingPoint DVLabs

November 9th, 2011: PacSec

自己紹介

• ブログ– http://dvlabs.tippingpoint.com/team/aportnoy– http://dvlabs.tippingpoint.com/team/lbrown

• TippingPoint DVLabs (TSRT)– Security Research / Vuln Discovery

– http://dvlabs.tippingpoint.com/appearances– http://dvlabs.tippingpoint.com/advisories/published

• Zero Day Initiative– http://www.zerodayinitiative.com

http://dvlabs.tippingpoint.com/team/aportnoy

http://dvlabs.tippingpoint.com/team/lbrown

http://dvlabs.tippingpoint.com/appearances

http://dvlabs.tippingpoint.com/advisories/published

http://www.zerodayinitiative.com/

プレゼンテーションの趣旨

• Shockwave の脆弱性を簡単に確認する方法– 現時点で唯一の方法…

• 見慣れないコードベース / ファイルのフォーマットの調査– 最初のアプローチとその欠点

– 個人 vs. チームコラボレーション– “ 下手な” ファジング vs. “ スマートな” ファジング

• とても徹底的（または抽象的）なアプローチ– ツールの進化– 利用したテクニック– レッスンから学ぶ

もう少し言わせてもらうと

• まず、誰もが思っていると思いますが…

• “4 億 5000 万以上のインターネットに接続されたデスクトップに Adobe Shockwave Player はインストールされている” -Adobe– とてつもなく巨大なボットネットだ

!=Flash

TSRT が Shockwave の脆弱性を発見

• 発見したゼロデイは…– ファイルのファジングによって発見した– ファイルフォーマットについて文書化されてなかった– バックトレースによって序数でエクスポートされてい

る関数が判明– iml32.dll ( 合計 766)– dirapi.dll ( 合計 368)

• 我々の最初の疑問– Shockwave は本当に悪用可能か？– すでに報告されていないか？– なぜこのバグが起きるのか？

TSRT が Shockwave の脆弱性を発見（続き）

• 我々がベンダに提示しようとするもの– 欠陥があるコードの場所– 最小限のトリガー (PoC)– 悪い結果をもたらす値または条件

– 通常はリバースエンジニアリングする必要がある

• 本題に入る前に…– このプレゼンテーションはバージョン 11.5.8.612 を前

提にしています。

最初の印象

• 構造体の操作でクラッシュ– Iml32 の序数のうち、確実にヒープ操作をするものは？

– シンボルもストリングも無い– 標準的な手法…

– WinDBG !heap 拡張の助けを借りる– !heap –p –a <address>

– ユーザーモードスタックトレース DB が alloc スタックを表示

0:008> !heap -p -a @eax address 03910020 found in _HEAP @ 150000 HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 03910018 20000 0000 [0b] 03910020 100000 – Trace: 2712 7c96eed2 ntdll!RtlDebugAllocateHeap+0x000000e1 7c94b394 ntdll!RtlAllocateHeapSlowly+0x00000044 7c918f21 ntdll!RtlAllocateHeap+0x00000e64 7c80ff0f kernel32!GlobalAlloc+0x00000066 690148aa IML32!Ordinal1218+0x0000002a

!heap を使ってみたが…

0:008> !heap -p -a @eax address 03910020 found in _HEAP @ 150000 HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 03910018 20000 0000 [0b] 03910020 100000 – Trace: 2712 7c96eed2 ntdll!RtlDebugAllocateHeap+0x000000e1 7c94b394 ntdll!RtlAllocateHeapSlowly+0x00000044 7c918f21 ntdll!RtlAllocateHeap+0x00000e64 7c80ff0f kernel32!GlobalAlloc+0x00000066 690148aa IML32!Ordinal1218+0x0000002a

!heap を使ってみたが…

何これ？

これではダメだ

• 実感 #1– メモリマネージャでは、

– Windows Heap は使われていない– !heap/PageHeap/etc も使われていない…

昔ながらの方法を試す

• ゼロデイのバグの調査は時間がかかる– 3 週間で結果を出すことを期待されていた– 我々は 1 週間に 30 以上の脆弱性報告を受け取っている

– どうすれば速く検証できるか？

• フォールトした命令は必ずしも有用ではない– ヒープ破損はさまざまな方法で実現できる– 多くのクラッシュはバグの原因を示さない

– 注意が他に逸らされていないか？– 同じ過ちを犯していないか確認する必要がある

昔ながらの方法を試す（続き）

• メモリマネージャをスクリューリバーシング– かなり時間がかかる可能性がある– それなら最初からファジングデータを使って、リバー

スエンジニアリングすればいいじゃん

• 我々はプロセスがファイルを読み込むところを探さなければならない– 結局、 MSVCR71!read を使ってみた

– .text:690709C4 call ds:_read (iml32, base 0x69001000)

– Shockwave は変な単位でバイトを読んでいる

昔ながらの方法を試す（続き）

• 実現可能な解決策– 我々は巧妙なブレイクポイントを仕掛けることができ

る– Read呼び出し後の対象バッファに書き込まれる直前

の場所を探す

• コンテキストスイッチは貴重– これはインスツルメンテーションのための仕事してい

る！

動的バイナリインスツルメンテーション（ DBI ）

• DBI （ read フッキング）は任意のロジックの挿入が可能– 我々は任意のアセンブラでどこでもフックすることができる– これは新しいことではなく、 80年代（あるいはそれ以前）から存在する

• いくつかの異なるインスツルメンテーションのフレームワークがある– DynamoRIO (http://dynamorio.org)– Pin (http://pintool.org)– ERESI (http://www.eresi-project.org)

• 我々は専用の内部ライブラリを持っている– これともう一つ別のフレームワークを使用してデモすることがで

きます。

http://dynamorio.org/

http://dynamorio.org/

http://pintool.org/

http://www.eresi-project.org/

http://www.eresi-project.org/

動的バイナリインスツルメンテーション（続き）

• 機能の基本的な概要– メモリの確保 / 解放する機能がある– これを利用して、特定のモジュール内からコードを“取

り出す“ことができる

• フックの実装– 目的のフックポイントで jmp を挿入することによって

実行させたいアセンブラへジャンプする– その後、取り出したコードにジャンプする– 取り出したコードから元のモジュールにジャンプする

ように、 jmp を挿入する


メモリを VirtualAlloc する

0xwhatever:



0xwhatever:

オリジナルコードを取り出す



0xwhatever:

戻るための jmp 命令を書く

jmp IML32_1128+0x05



0xwhatever:

<our asm logic>

実行させたいコードを書く

jmp IML32_1128+0x05

0xwhatever2:



0xwhatever:

jmp を挿入する

jmp far 0xwhatever2

<our asm logic>

jmp IML32_1128+0x05

0xwhatever2:



0xwhatever:

取り出したコードへの jmp 命令を書く

jmp far 0xwhatever2

<our asm logic>

jmp IML32_1128+0x05

0xwhatever2:

jmp 0xwhatever

ファイル読み込みのフック

• 最初のアプローチ– Shockwave による Read呼び出しをフックする– バッファの内容とサイズを保存する– Read呼び出しの後にフックして、バッファを調べる

– ファジングされたファイルデータのために– これでもうまくいくが、もっと一般的な方法がある…

• MSVCR71!read そのものをフックする– 他のプロジェクトのためにフックを再利用できる– 後でこれが非常に有用であることが判明した…

ファイル読み込みのフック（続き）

• MSVCR71.dll version 7.10.3052.4, base 0x7C341000– フック #1

– .text:7C36364F mov eax, ebx– 先頭付近で引数を横取り

– フック #2– .text:7C3636BA jmp short loc_7C3636DD– 終端付近にデータがかたまってるバッファを探す


[BITS 32]

push ecxpush esi

mov ecx, [esp+0x14]mov esi, [esp+0x10]

mov [_symCount], ecxmov [_symBuf], esi

pop esipop ecx

[BITS 32]pushadpushfd

mov ecx, [_symCount]mov esi, [_symBuf]

shr ecx, 2mov eax, _symNeedle

TEXT.loop cmp [esi], eax jnz .increment jmp .success

.increment lea esi, [esi+4] dec ecx jz .fail jmp .loop

.success int3

.fail jmp .exit

.exit popfd popad



• このコードは nasm によりアセンブルされたもの– 結果のオペコードは我々のフレームワークを使用して挿

入– 挿入時に静的なアドレス / 値を動的に置き換える

– ありがとう、 Python


• プロセスがロードされた後、フックが挿入される– 探している DWORD を発見したときに、アセンブリが

INT3 （ブレイクポイント）を投げる– MSVCR71 がメモリにロードされている必要がある

– WinDBG で sxe ld:msvcr71 の後、挿入する

• このデータが読み込まれたら、リバースエンジニアリングを開始できる– @esi でのメモリのブレイクポイントを仕掛ける

– ba r1 @esi– Shockwave はいつも実際にデータを使用する前にイン

ライン memcpys のブレイクポイントがヒットする、そこで追加の bps を仕掛ける

S:\Tools\hooking>python.exe -i read_search.py 812 0x0000dc50[*] Injecting hooks[*] Successfully injected>>>


0000h: 52 49 46 58 00 00 DC 50 4D 56 39 33 69 6D 61 70 RIFX..ÜPMV93imap 0010h: 00 00 00 18 00 00 00 01 00 00 00 2C 00 00 07 3A ...........,...: 0020h: 00 00 00 00 00 00 00 00 00 00 00 00 6D 6D 61 70 ............mmap

ファイルデータ (0x0000dc50 に注目 ):

msvcr71 フックを挿入 :

0:015> sxe ld:dirapi0:015> sxe ld:iml320:015> gModLoad: 69000000 6910b000 C:\WINDOWS\system32\Adobe\Shockwave 11\IML32.dlleax=7c37b9b0 ebx=00000000 ecx=7c37d5b8 edx=03b4285f esi=00000000 edi=00000000eip=7c90e514 esp=025dca04 ebp=025dcaf8 iopl=0 nv up ei ng nz ac pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000296ntdll!KiFastSystemCallRet:7c90e514 c3 ret0:008> g(32c.210): Break instruction exception - code 80000003 (first chance)eax=50dc0000 ebx=00000000 ecx=00001fff edx=03b71fc0 esi=04712a10 edi=04712a0ceip=03b60089 esp=025dbaa4 ebp=00000003 iopl=0 nv up ei pl zr na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=0000024603b60089 cc int 30:008> dc esi L304712a10 50dc0000 3339564d 70616d69 ...PMV93imap


0:015> sxe ld:dirapi0:015> sxe ld:iml320:015> gModLoad: 69000000 6910b000 C:\WINDOWS\system32\Adobe\Shockwave 11\IML32.dlleax=7c37b9b0 ebx=00000000 ecx=7c37d5b8 edx=03b4285f esi=00000000 edi=00000000eip=7c90e514 esp=025dca04 ebp=025dcaf8 iopl=0 nv up ei ng nz ac pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000296ntdll!KiFastSystemCallRet:7c90e514 c3 ret0:008> g(32c.210): Break instruction exception - code 80000003 (first chance)eax=50dc0000 ebx=00000000 ecx=00001fff edx=03b71fc0 esi=04712a10 edi=04712a0ceip=03b60089 esp=025dbaa4 ebp=00000003 iopl=0 nv up ei pl zr na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=0000024603b60089 cc int 30:008> dc esi L304712a10 50dc0000 3339564d 70616d69 ...PMV93imap


ファイルデータ

バグの調査に立ち返る

• フックを使用することで、我々はパーサーを見つけることに成功した– この時点では指定した値がどのように使われているか知るために

簡単なリバースエンジニアリングをしただけ– 幸い、我々はすぐに論理的な欠点を見るけることができた

• 序数なんてナンセンス？– 我々は dirapi と iml32 から多くの序数への呼び出しを知った– … で、我々は単純にリバースエンジニアリングする必要が無いと考えた（誰がメモリマネージャーをリバースエンジニアリングしたいと思うんだろう？）

– Brett Moore– Matt Conover– Chris Valasek & John McDonald– Nico Waisman– Sean Heelan & Agustin Gianni

バグの調査に立ち返る（続き）

• そう、これでこの検証は終了して、次に進むことにした– 我々の取ったプロセスと 4日という所要時間に満足して

いた

かいじゅうたちのいるところ

• 1 つのバグがあるところ、より多くのバグあり– この時点でやっと我々はファジングをすることにした

• 最初に、ファイルフォーマットを解析したかった– 圧縮されたデータをファジングしても意味が無い– ファイルフォーマットの構造体にクラッシュの結果を結びつけるとよかった

Director ファイルフォーマット

• Shockwave ファイルは Director Studio から作られる– だから拡張子は .dir

– zlib圧縮は .dcr

• DIR フォーマットの実体は RIFF– 実は、ビッグエンディアン RIFF (RIFX magic で示され

る )– まるで AVI 、ただのコンテナフォーマット– 我々は以前行った DirectShow のリサーチでこれらに多

少精通していた

RIFX フォーマット

0000h: 52 49 46 58 00 00 DC 50 4D 56 39 33 69 6D 61 70 RIFX..ÜPMV93imap 0010h: 00 00 00 18 00 00 00 01 00 00 00 2C 00 00 07 3A ...........,...: 0020h: 00 00 00 00 00 00 00 00 00 00 00 00 6D 6D 61 70 ............mmap 0030h: 00 00 0F E0 00 18 00 14 00 00 00 CA 00 00 00 97 ...à.......Ê...— 0040h: 00 00 00 90 FF FF FF FF 00 00 00 68 52 49 46 58 ...ÿÿÿÿ...hRIFX �0050h: 00 00 DC 50 00 00 00 00 00 01 00 00 00 00 00 00 ..ÜP............ 0060h: 69 6D 61 70 00 00 00 18 00 00 00 0C 00 01 00 00 imap............ 0070h: 0A AF D9 24 6D 6D 61 70 00 00 0F E0 00 00 00 2C .¯Ù$mmap...à..., 0080h: 00 00 00 00 0A AF B0 AC 4B 45 59 2A 00 00 02 28 .....¯°¬KEY*...( 0090h: 00 00 10 14 00 00 00 00 00 00 00 00 43 41 53 74 ............CASt 00A0h: 00 00 1D 2C 00 00 38 B6 00 00 00 00 00 00 00 00 ...,..8¶........ 00B0h: 66 72 65 65 00 00 00 00 00 00 00 00 00 0C 00 00 free............ 00C0h: 00 00 00 75 66 72 65 65 00 00 00 00 00 00 00 00 ...ufree........ 00D0h: 00 0C 00 00 00 00 00 05 66 72 65 65 00 00 00 00 ........free.... 00E0h: 00 00 00 00 00 0C 00 00 00 00 00 06 66 72 65 65 ............free

RIFX フォーマット（続き）

0000h: 52 49 46 58 00 00 DC 50 4D 56 39 33 69 6D 61 70 RIFX..ÜPMV93imap 0010h: 00 00 00 18 00 00 00 01 00 00 00 2C 00 00 07 3A ...........,...: 0020h: 00 00 00 00 00 00 00 00 00 00 00 00 6D 6D 61 70 ............mmap 0030h: 00 00 0F E0 00 18 00 14 00 00 00 CA 00 00 00 97 ...à.......Ê...— 0040h: 00 00 00 90 FF FF FF FF 00 00 00 68 52 49 46 58 ...ÿÿÿÿ...hRIFX �0050h: 00 00 DC 50 00 00 00 00 00 01 00 00 00 00 00 00 ..ÜP............ 0060h: 69 6D 61 70 00 00 00 18 00 00 00 0C 00 01 00 00 imap............ 0070h: 0A AF D9 24 6D 6D 61 70 00 00 0F E0 00 00 00 2C .¯Ù$mmap...à..., 0080h: 00 00 00 00 0A AF B0 AC 4B 45 59 2A 00 00 02 28 .....¯°¬KEY*...( 0090h: 00 00 10 14 00 00 00 00 00 00 00 00 43 41 53 74 ............CASt 00A0h: 00 00 1D 2C 00 00 38 B6 00 00 00 00 00 00 00 00 ...,..8¶........ 00B0h: 66 72 65 65 00 00 00 00 00 00 00 00 00 0C 00 00 free............ 00C0h: 00 00 00 75 66 72 65 65 00 00 00 00 00 00 00 00 ...ufree........ 00D0h: 00 0C 00 00 00 00 00 05 66 72 65 65 00 00 00 00 ........free.... 00E0h: 00 00 00 00 00 0C 00 00 00 00 00 06 66 72 65 65 ............free

RIFX の解析

• 我々は MSVCR71!read インジェクションを使用してパーサーを発見することができた– サーチキーを‘ RIFX’ に仕掛ける

• パーサーは dirapi モジュールから始まることが判明– Dirapi の序数番号 82

– メモリマネージャーの初期化をを呼び出す役割も持ち合わせている

5926 ノード323176 エッジ

Dirapi!Ordinal_82

ここをズームしてみよう…

Dirapi!Ordinal_82

Dirapi!Ordinal_82 （続き）

パーサーのリバースエンジニアリング

• 我々はこれをすべてステップ実行したくない– ファイル形式がチャンクに基づいているとして、我々

が目指すコードを分離できるに違いない

• IDAPython の出番– FourCC 発見コードを実装するのが簡単

– すぐにすべての cmp reg32 を発見

パーサーのリバースエンジニアリング（続き）

• かなりの数があると判明– IDA の新しい simplecustviewer_t を使って表示することができる

• 使ったコードは公開予定– 参考 : http://www.hexblog.com/?p=119

• そうそう、 010 template も使えます– http://www.sweetscape.com/010editor/ – 興味があれば E-mail ください

http://www.hexblog.com/?p=119

http://www.sweetscape.com/010editor/

http://www.sweetscape.com/010editor/

パーサーのリバースエンジニアリング（続き）

アタックポイントの列挙

• 我々は .dir に多くの FourCC があることに気付いた– Shockwave が別のフォーマットを解析すると理解

– 調べたところ、 Shockwave は”アセットファイル”をオンデマンドでダウンロードする

– このファイルの拡張子は .x32– ネットワークトラッフィックをスニフィングすれば、これ

が Shockwave のサーバーから落とされているのが見える

• 君はこの脆弱なコンポーネントを持ってないの？– では、君のためにダウンロードしよう…

アタックポイントの列挙（続き）

• スリム vs フルの Shockwave （ここに怪獣が）


• Zef と私は週末をこの調査に費やした– Shockwave は必要なときに .w32 ファイルをダウンロードする

– これは ZLIB で圧縮されている– .x32 アセットモジュールを含んでいる（ PE フォーマット）

• マンインザミドルで接続を試みた (evilgrade で )– CERT チャンクに証明書が埋め込まれていることが判明– しかも、ちゃんとした証明書が

0000h: 52 49 46 46 00 06 9D 4F 50 43 4B 32 49 4E 46 4F RIFF..OPCK2INFO �0010h: 00 00 00 A2 00 00 00 18 00 00 00 03 00 00 00 00 ...¢............ 0020h: 00 00 00 00 00 00 00 9B 00 00 00 8A 78 DA 35 CB .......›...ŠxÚ5Ë 0030h: 3B 12 82 30 10 00 D0 3D CA 96 DA F0 0B 82 D8 59 ;.‚0..Ð=Ê–Úð.‚ØY 0040h: DA D8 C0 38 B6 F9 AC C2 38 10 66 B3 18 BD BD 69 ÚØÀ8¶ù¬Â8.f³.½½i 0050h: EC DF 1B E8 23 77 61 0D 67 E7 0D 61 FF 0D 42 73 ìß.è#wa.gç.aÿ.Bs 0060h: C0 CB 62 3D AF 9E B5 90 83 E1 6F E0 46 3C F5 D3 ÀËb=¯žµƒáoàF<õÓ �0070h: 73 C1 81 B7 20 78 25 89 9E 5F 09 70 3A FE 81 5B sÁ· x%‰ž_.p:þ[ � �0080h: 20 D4 82 A3 C8 1A 4E 79 1E 63 CC DE A9 84 54 32 Ô‚£È.Ny.cÌÞ©„T2 0090h: EB E7 9C 57 8D 3B BB 2F 6A 00 E5 AA CA E8 C6 18 ëçœW;»/j.åªÊèÆ. �00A0h: 65 0A 7B B0 65 D5 76 D4 D6 CD D1 2A D7 36 54 76 e.{°eÕvÔÖÍÑ*×6Tv 00B0h: 00 3F B9 E7 33 16 46 4C 53 54 00 00 00 24 00 00 .?¹ç3.FLST...$.. 00C0h: 00 08 00 00 00 01 00 00 00 00 54 65 78 74 58 74 ..........TextXt 00D0h: 72 61 2E 78 33 32 00 31 31 2E 35 2E 38 72 36 31 ra.x32.11.5.8r61 00E0h: 32 00 53 49 47 4E 00 00 00 40 23 87 1A 11 A1 E9 2.SIGN...@#‡..¡é 00F0h: D1 75 BE EE 08 BA E6 73 89 6A 2E 58 B0 CE EA 53 Ñu¾î.ºæs‰j.X°ÎêS 0100h: E1 BA D5 16 94 4D 28 7C 7B C8 AD 1F 16 D6 60 D0 áºÕ.”M(|{È ..Ö`Ð 0110h: 48 BB 25 9A C7 22 C6 68 E3 75 B7 A3 83 01 3C 64 H»%šÇ"Æhãu·£ƒ.<d 0120h: BC 1C FC 9B FB C7 D7 0A 89 2C 43 45 52 54 00 00 ¼.ü›ûÇ×.‰,CERT..


• 我々は .dir に立ち返り、サンプルが必要であると判断した– そして Director Studio を学ぶために Derek をチームに引き入れた– 彼のファジングのノウハウで Logan を助けることができた– それがチームにとって大きな効果をもたらした…

• Derek は Director Studio を使ってデータを埋め込むことができた– 3D アセット– フォント– 画像– 動画– Lingo– …

サンプルファイルの生成

• 我々のファジング環境はすでに確立されている– 物理マシンと仮想マシン– pydbg の下でターゲットのプロセスを動かす– IRC ボットがファザーからのクラッシュ情報を受け取る

– ボットはさらに以下のコマンドを受け付ける– ターゲットの切り替え– 値 / メソッドの変更– マシンの追加 /削除– …

• 単純なビット反転が驚くほど有効だった– 最初の実行で約 2500 のクラッシュを得た

ファジング環境

脆弱性検証のクラウドソーシング

• ちょうどこの頃、 Reconカンファレンスに出展しようとしていた– Recon でコンテストを出すことを考え– クラウドソースの脆弱性検証をしてみることになった

• 我々が見つけた Shockwave のバグから 10 個選んだ– … そしてカンファレンス参加者に配布した– これらの脆弱性を最も悪用できた人に $2500USD が与えられた

– TPTI-10-12 - Adobe Shockwave TextXtra Allocator Integer Overflow Remote Code Execution Vulnerability

– TPTI-10-11 - Adobe Shockwave tSAC Chunk Pointer Offset Memory Corruption Remote Code Execution Vulnerability

– TPTI-10-10 - Adobe Shockwave tSAC Chunk Invalid Seek Memory Corruption Remote Code Execution Vulnerability

– TPTI-10-09 - Adobe Shockwave CSWV Chunk Memory Corruption Remote Code Execution Vulnerability

http://dvlabs.tippingpoint.com/advisory/TPTI-10-12




• Recon開催中、我々はさらにファザーを改善した– RIFF チャンクを認識するように修正

– チャンクサイズファジング、構造体のカウント、など

• テキサスに戻り、さらに多くのクラッシュを発見– 約 4000 の新しいクラッシュ– クラッシュ調査（ Crush binning ）をさらに改善することにした

Efficiency++ （さらなる効率化）

Crash binning

• binning の目的は一意性を決定することにある– 違反のタイプ (read/write/execute)– エラーが発生するアドレス（モジュール）– フォールトする命令およびその周辺の逆アセンブル– 該当するファイルデータの 16 進ダンプ– スタックの呼び出し

• チャンクのナレッジをバイナリに活用– 一意性を確定する最良の特徴はファジングデータ内に見られるチャ

ンクだった

インジェクション + ファジング = 勝利

• メモリレイアウトの仮定– ブラウザ内で下位のメモリ範囲に影響を与えることができる– アドレスの読み取りでクラッシュが発生している場合、ヒープスプ

レーによってメモリに攻撃を入ることができる

• ヒープスプレーを”シミュレート”するためにインジェクションを使うことができる– ntdll!KiUserExceptionDispatcher フックによって

– アクセス違反を書き換える– オンデマンドでメモリを確保する

インジェクション + ファジング = 勝利（続き）

typedef struct _EXCEPTION_RECORD { DWORD ExceptionCode; DWORD ExceptionFlags; struct _EXCEPTION_RECORD *ExceptionRecord; PVOID ExceptionAddress; DWORD NumberParameters; ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS]; } EXCEPTION_RECORD, *PEXCEPTION_RECORD;

• MSDN より :

• もし意図する範囲のアドレスが読み込まれたら…– VirtualAlloc の呼び出しを挿入し、バッファをインラインで memset

する– その後、何事もなかったかのようにプロセスに実行を返す– これによりかなりの数の読み込み違反を見つけることができた

– この違反は悪用可能な脆弱性の存在を示している

• ntdll.dll version 5.1.2600.5755 でテストした– 0x7C90E48A 、 base 0x7C901000 に挿入


• VirtualAlloc を呼び出してプロセスに実行を返す場合、 ZwContinue にジャンプする


DIR ファイルのファジング

• 4000 ものクラッシュの解析には時間がかかる– 推定 : 最初のゼロデイのバグには 4日、全部で 44年かかる– はい。これはちょっと大げさかな

• ありがたいことに、 Logan の crash binning によって解析の目途がついた– 明確に悪用可能なバグをリバースすることに成功– そして以下を公表した :

– TPTI-10-13 - Adobe Shockwave Director tSAC Chunk Remote Code Execution Vulnerability

– TPTI-10-14 - Adobe Shockwave Director rcsL Chunk Pointer Offset Remote Code Execution Vulnerability

– TPTI-10-15 - Adobe Shockwave Director mmap Trusted Chunk Size Remote Code Execution Vulnerability

– TPTI-11-01 - Adobe Shockwave dirapi.dll IFWV Trusted Offset Remote Code Execution Vulnerability

– TPTI-11-02 - Adobe Shockwave TextXtra Invalid Seek Remote Code Execution Vulnerability

– TPTI-11-03 - Adobe Shockwave Font Xtra String Decoding Remote Code Execution Vulnerability

– TPTI-11-05 - Adobe Shockwave PFR1 Font Chunk Parsing Remote Code Execution Vulnerability








DIR ファイルのファジング

• ゼロデイ脆弱性は一般に公開された– 残りの Shockwave のバグを 2010年に 2日おきに公表

• いま我々は大きな問題を抱えている– もうぼんやり座っていても何千ものクラッシュを起こ

すことができる– ゼロデイのリサーチャーの迅速な対応に期待する– 我々はバグがユニークであるか確認する必要がある

Shockwave メモリマネージャ再考

• 我々の得た結論– メモリマネージャをリバースエンジニアリングしなければならな

い– 少なくともアロケーションを追跡するのに十分な程度– ユニークさには自信のある唯一の方法

• 幸いにもスタート地点は得られた– 全てのヒープの確保が GlobalAlloc から来ており、ブ

レークポイントをそこに置くことで解析を開始することができる。


• iml32内に GlobalAlloc を呼び出すラッパーの存在が判明– より重要な点として、序数 1135 の関数が初期化処理のように見え

る

Breakpoint 0 hiteax=00000000 ebx=00000000 ecx=00000000 edx=00004008 esi=00004008 edi=7c80fdcdeip=7c80fdcd esp=025dd470 ebp=00004000 iopl=0 nv up ei pl zr na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246kernel32!GlobalAlloc:7c80fdcd 6a1c push 1Ch0:008> kvChildEBP RetAddr Args to Child 025dd46c 690148aa 00000030 00004008 00004008 kernel32!GlobalAlloc025dd480 69009071 00004008 00000001 00009100 IML32!Ordinal1218+0x2a025dd49c 690804e0 00004000 00009100 00000001 IML32!Ordinal9233+0x907100000000 00000000 00000000 00000000 00000000 IML32!Ordinal2064+0x64d00:008> dd @esp L14025dd470 690148aa 00000030 00004008 00004008025dd480 00000001 69009071 00004008 00000001025dd490 00009100 00000000 00008000 00000000025dd4a0 690804e0 00004000 00009100 00000001025dd4b0 00000000 00000000 00000000 6900966f0:008> ub 6900966f L3IML32!Ordinal1135+0x287:69009667 52 push edx69009668 6a20 push 20h6900966a e8f16f0700 call IML32!Ordinal2064+0x6650 (69080660)


Breakpoint 0 hiteax=00000000 ebx=00000000 ecx=00000000 edx=00004008 esi=00004008 edi=7c80fdcdeip=7c80fdcd esp=025dd470 ebp=00004000 iopl=0 nv up ei pl zr na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246kernel32!GlobalAlloc:7c80fdcd 6a1c push 1Ch0:008> kvChildEBP RetAddr Args to Child 025dd46c 690148aa 00000030 00004008 00004008 kernel32!GlobalAlloc025dd480 69009071 00004008 00000001 00009100 IML32!Ordinal1218+0x2a025dd49c 690804e0 00004000 00009100 00000001 IML32!Ordinal9233+0x907100000000 00000000 00000000 00000000 00000000 IML32!Ordinal2064+0x64d00:008> dd @esp L14025dd470 690148aa 00000030 00004008 00004008025dd480 00000001 69009071 00004008 00000001025dd490 00009100 00000000 00008000 00000000025dd4a0 690804e0 00004000 00009100 00000001025dd4b0 00000000 00000000 00000000 6900966f0:008> ub 6900966f L3IML32!Ordinal1135+0x287:69009667 52 push edx69009668 6a20 push 20h6900966a e8f16f0700 call IML32!Ordinal2064+0x6650 (69080660)


@ebp fail


• 序数 1135 の関数周辺の処理を調査…– Shockwave のバイナリの中に、エラーハンドラに関する有用な文字列を発見

• … この SmartHeap とはいったい ?– 少なくとも、この文字列を使用する関数によって有用な実行経路を知ることができた

SmartHeap とは

• SmartHeap についてはこのあたりを参照 (>20年 )– MicroQuill 製 : http://www.microquill.com/smartheap/index.html – まだ誰もリバースエンジニアリング / ドキュメント化していない模様

• おお、 API のドキュメントが !– http://www.microquill.com/kb/docs/01_intro.html – 束の間の勝利…

– 5種類の利用可能な API– ANSI C– C++– 固定サイズ– ポインタベース– ハンドルベース

http://www.microquill.com/smartheap/index.html

http://www.microquill.com/smartheap/index.html

http://www.microquill.com/kb/docs/01_intro.html

http://www.microquill.com/kb/docs/01_intro.html

SmartHeap とは（続き）

• 残念ながらシンボル情報は無し– API のドキュメントをバイナリとマッピングする単純な方法はない

– 序数での照合は手間がかかる– さらに、ドキュメントには構造体の定義が含まれていない

• そして、 iml32 が * ただの *SmartHeap でないことも判明…– メモリマネージメントに対して、抽象化層を切り出すことにした– 幸いなことに、 SmartHeap のアーキテクチャはこの仕事に向いて

いる

iml32.dll を細切れに

iml32.dll を細切れに（続き）

• これらのグローバルなもの (およびそのデータの参照 ) は有用– これらを相互に参照する関数はメモリマネージャの一部とみなせる

– これらのチャイルド関数も同様

• IDAPython での支援– いくらかの応急的な IDApy foo により関数のリストを取得– さて次は ?

iml32.dll を細切れに（続き）

• この時点で、特定の機能を見つける必要があった– すべてのメモリマネージャは malloc と free を持っているはず

– そしてこれらは実行中に何度も呼ばれるはず

• 実行時のヒストグラムを作ろう– iml32 のロードからアンロードまで– 95種類の関数をケア– どれくらいの頻度で呼び出されるか不明– ブレークポイントを設定し、一時レジスタをインクリメントさせ

ることは可能– または、フックすることでコンテキストスイッチの挙動が不要

実行時のヒストグラム

• まず最初にデータ保持用のメモリを確保– 4 バイト * 95 関数 = 380 バイトを確保– すべての関数にインクリメント用のインデックスを割り当て

• 非常に高速に動作し、適切な結果が得られた– IDA subview を再び使用

pushadpushfmov eax, _symArenamov ebx, _symIndexinc dword [eax+ebx*4]popfpopad

インジェクションにより動的に解決

PyDbgExt

• Flier Lu がありがたいことに PyDbgExt を書いてくれた– http://sourceforge.net/projects/pydbgext – WinDBG 内で Python を動かすことが可能– 残念ながらバグが多く、適切に動作させるためには手作業での修正

と再コンパイルが必要

• メモリ内のヒストグラム読み込みのために PyDbgExt を使用– IDAへインポートするためのディスクへの書きだしにも

http://sourceforge.net/projects/pydbgext

http://sourceforge.net/projects/pydbgext

PyDbgExt （続き）

0:008> !load pydbgext0:008> !helpHelp for pydbgext.dll

[Environment]

Extension Image : 0.1.0.48 Python Version : 2.6.6rc1

[Usage]

eval : Evaluate a python expressionimport : Import a python modulefrom : Import a list of symbols from a python moduleprint : Evaluate and then print a python expressionexec : Execute a python scripthelp : Shows this helppy : Evaluate a python expression

実行時のヒストグラム（続き）


ヒープの初期化が一度だけ呼ばれる


これらのどれかひとつが malloc, どれかが free, どれかが realloc

アロケータの解析

• 関数のプロトタイプを確認し、 malloc を発見– IML32!Ordinal1111

• 我々が知っている malloc のようには働かないことを除き…– 呼び出し側を解析

– 序数 1111 の関数は実際のバッファを返すようには見えない– かわりに、構造体のポインタを返している

– 使用されるバッファのポインタを格納している

• 序数 1111 の関数は、常に既存の構造体のポインタを返している– その要素を更新している

001ee218 001ee204 baadf00d baadf00d baadf00d baadf00d <--- 未アロケート001ee22c 001ee218 baadf00d baadf00d baadf00d baadf00d <--- 未アロケート001ee240 001ee22c baadf00d baadf00d baadf00d baadf00d ...001ee254 001ee240 baadf00d baadf00d baadf00d baadf00d001ee268 001ee254 baadf00d baadf00d baadf00d baadf00d001ee27c 001ee268 baadf00d baadf00d baadf00d baadf00d001ee290 001ee27c baadf00d baadf00d baadf00d baadf00d001ee2a4 001ee290 baadf00d baadf00d baadf00d baadf00d ...001ee2b8 001ee2a4 baadf00d baadf00d baadf00d baadf00d <--- 未アロケート001ee2cc 045cffe0 00000030 baad0001 baadf001 baadf001 <--- アロケート済み 001ee2e0 abababab abababab 00002774 00000000 080403a2001ee2f4 00ee14ee 00150178 00163018 feeefeee feeefeee

アロケータのデバッグ




序数 1111 の関数が返すポインタ




アロケートされたバッファのポインタ

アロケータのデバッグ（続き）

• 厳密には、戻り値はポインタではない– ハンドルである– ハンドルベースの API でなければならない– IML32!Ordinal1111 は imMemHandleNew でなければならない

HandleEntry._fields_ = [ (ptr(HandleEntry), 'prev'), (uint32_t, 'size'), (uint32_t, 'alloc_flag'), (uint32_t, 'flag1'), (uint32_t, 'flag2')]

アロケータのデバッグ（続き）

• ハンドルがフェッチされるテーブルは事前に確保される– すべてのハンドルのアドレスはヒープの初期化時に決定される– グローバル空間の 0x690AC084 を逆参照することにより探索可能

• WinDBG にてそれを可能にする PyDbgExt に再び感謝– PyKD は当時利用できなかった

poi(0x690AC084)+0x1c = ハンドルテーブル内で最後に解放されたエントリのポインタpoi(0x690AC084)+0x20 = ハンドルテーブルの開始ポインタ

SmartHeap向けの !heap を実装

• ハンドルテーブルの横断は有益– SmartHeap向けの !heap の実装の最初の一歩– 具体的には , !heap –a < アドレス >

– “指定アドレスを含んでいるチャンクの検索”

0:008> !exec S:\research\smartheap\sheap.py –a 0x043d0529[*] Handle table starts at 0x001eb140[*] Handle table ends at 0x001ef0dc[*] Searching for chunk containing address 0x043d0529...[*] Found address inside handle table entry at 0x001ef0f0<class '__main__.HandleEntry'>[1ef0f0] (HandleEntry)'> prev '(\x05=\x04'[1ef0f4] size '\x04\x08\x00\x00'[1ef0f8] alloc_flag '\x01\x00\xad\xba'[1ef0fc] flag1 '\x00\xf0\xad\xba'[1ef100] flag2 '\x00\xf0\xad\xba'

SmartHeap向けの !heap を実装（続き）

• 欲しい機能…– !heap –p –a < アドレス > はさらに役立つ

– Gflags.exe からのユーザーモードのスタックトレース DBオプション

– “指定されたアドレスが含まれるチャンクを検索し、さらにそれが割り当てられたときの呼び出すスタックを取得”

– これは、ファジングによるクラッシュを特定する場合やゼロデイを発見する場合に非常に有用

• アロケータにブレークポイントを配置し保存することが可能…– 13000回も呼び出される、速度上のやっかいな問題点を除く

– 再度、インジェクションによる回避

ユーザーモードのスタックトレース DB

• このフックはもう少し複雑…– まず、挿入より前にコールスタックを格納する場所を確保– Python でそれを表現する構造体を定義 :

• データ片の選択が唯一必要– アロケートされたアドレスと保存された戻り番地

CallStack._fields_ = [ (uint32_t, 'alloc_address'), (uint32_t, 'funcret1'), (uint32_t, 'funcret2'), (uint32_t, 'funcret3'), (uint32_t, 'funcret4'), (uint32_t, 'funcret5'), (uint32_t, 'funcret6'), (uint32_t, 'funcret7'), (uint32_t, 'funcret8')]

ユーザーモードのスタックトレース DB （続き）

• 次に iml32!Ordinal1111 をフック– 具体的には、エピローグ– 手作業でのスタックの探索が必要 (@ebp ベースのフレームではな

い )– iml32 と dirapi のベースを 0x69001000 と 0x68001000 と見なす

– ASLR が有効でも、 0x6xxxxxxx となる

• このフックはスタック上の dword の下位バイトの AND をとる– 0x69 または 0x68 であるならメモリ領域に保存する– 安直なコールスタックの手法だが、有効に機能する

0:008> !exec S:\research\smartheap\sheap.py –p –a 0x04560529[*] Handle table starts at 0x001ed038[*] Handle table's last free entry at 0x001f0fd4[*] Searching for chunk containing address 0x04560529...[*] Found address inside handle table entry at 0x001f0fe8[*] Searching for stack trace for allocation at 0x04560528[*] Found call stack for allocation starting at 0x04560528:0x6900a295 0x6901b4b0 0x690aa518 0x6901b54e 0x69000000 0x69019ab9 0x69000000 0x00000000

ユーザーモードのスタックトレース DB （続き）

コールスタックの再構築

• 以上で調査のためのスタート地点といくらかのデータを把握– これで疑似コールバック内の関数上に条件付きブレークポイントを設定できるようになった

– そして、スタックを解析し真のコールスタックを構築するためにIDA を利用

• ステップバイステップ– bp を設定 ( アンカーを設定 )– @eip と @esp を取得– スタックの差分を IDA で確認– スタック上の dword をモジュールのアドレス範囲と照合

0:010> kChildEBP RetAddr 025dd8a4 69010c03 IML32!Ordinal1218+0x230025dd8bc 68091520 IML32!Ordinal1130+0x13025dd8ec 69009f30 DIRAPI!Ordinal418+0x49450025dd8f8 6800c492 IML32!Ordinal1113+0x20025dd900 680dac1a DIRAPI!Ordinal967+0xc2025dd908 680fecc1 DIRAPI!Ordinal418+0x92b4a025dd924 6811459e DIRAPI!Ordinal418+0xb6bf1025dd948 68114d55 DIRAPI!Ordinal418+0xcc4ce00000000 00000000 DIRAPI!Ordinal418+0xccc85

コールスタックの再構築（続き）

• 完全なコールスタックであっても、情報が欠落– 未知のシンボルが多すぎる

シンボル ?

• この時点で、 Shockwave が複数のプラットフォームに対応していることに気付いた– もしかすると他のプラットフォームにはシンボルがあるかも…

• 結局、 OS X には存在– ある程度– 我々のチームの Zef が Shockwave プロジェクトのこの部分を保有

– チームを持つことは素晴らしいことだと再認識…

シンボル ? （続き）

• OS X のコードは Windows と大きく異なる– そのため、関数をマッチさせる方法を見つける必要があった– 理想的には、こういった処理を自動化するための IDA スクリプト

を持っておくべき

• 既存のツールが利用可能… 本当に ?– Zef は最初に TurboDiff を試した– Zynamics^H^H^H^H^H^HGoogle BinDiff も同様

TurboDiff

BinDiff

• 正直に言うと、 v3.1 が最新バージョンであったが 3.0.0 しか所有していなかった

シンボルポーティング

• 類似しているが異なってる– 多くの関数は Mac と同じだったが、かなりの部分が違って見えた– ヒューリスティックを用いる必要があった

シンボルポーティング（続き）

• 初めにデーターを収集そして比較をする– IDAPython を使って関数 /基本ブロック / 命令を繰り返す– マークされたロケーション（ marked locations ）を使用して特徴を保存する– 特別な構文で

関数の特徴

• 見比べてみた– 相対している箇所– 呼び出し回数

Win32 OS X

• 相対する外部呼出しの数　– 以下は同じ、ヒューリスティックにより発見

関数の特徴（続き）

• サブグラフ比較– トップダウン式とボトムアップ式

– ノードの数– 分岐の数

– いくつかの関数はとても異なっていた– プラットフォーム固有コードと規則の違いのため



Win32 OS X


• 構造体– どのようなオフセットで構造体が参照されているか。　

– 要素サイズ– 要素タイプ

– どの関数に引数として構造体が渡されるか。– どこからリターンされるか

• IDA の開発者 Ilfakへのリクエスト– Idaapi で対応してほしい


Win32 OS X

• ループ– ループの数– ネスト階層


Win32 OS X

• 最初のステップ– 最も大きな“手ごたえ”は、既知の libc 関数の呼び出しにあった

– これで前述の特徴を用いて先に進むことができる• 成功！

– imMemHandleNew– imMemHandleLock/Unlock– imMemHandleGetSize – imBufferNew– imMemCopy– imStreamRead– MemPoolInitFS– MemPoolSetBlockSizeFS– MemPoolPreAllocateHandles– …


SmartHeap の解析に戻る

• 限られたシンボルを用いたリバースエンジニアリングは、しないよりした方がいい– シンボル内のハンドルへの参照がたくさんあることに気づいた

– SmartHeap にはハンドルベースの API– そして、我々は解析に戻りその API を使用した。

• これによって、資料にある関数のプロトタイプと一致させることができた– http://www.microquill.com/kb/docs/04_api.html

MEM_POOL MemPoolInitFS(unsigned short blockSize, unsigned long blockCount, unsigned flags);

unsigned long MemPoolPreAllocateHandles(MEM_POOL pool, unsigned long handleCount);

http://www.microquill.com/kb/docs/04_api.html

http://www.microquill.com/kb/docs/04_api.html

SmartHeap の解析に戻る（続き）

• これらのプロトタイプによってグローバル値を識別することができた– 値は固定長メモリプールへのポインタだった

SmartHeap の解析に戻って（続き）

• さらに、 MicroQuill は HeapAgent を作成していた– 開発者へ SmartHeap アプリケーションの測定を提供している

SmartHeap の解析に戻って（続き）

• HeapAgent はヘッダーファイルを含んでいる– いくつかの有用なデータを発見（デバッグに利用できる）

/* Flags passed to MemPoolInit, MemPoolInitFS */#define MEM_POOL_SHARED 0x0001u /* == TRUE for SH 1.5 compatibility */#define MEM_POOL_SERIALIZE 0x0002u /* pool used in more than one thread */#define MEM_POOL_VIRTUAL_LOCK 0x0004u /* pool is locked in physical memory */#define MEM_POOL_ZEROINIT 0x0008u /* malloc/new from pool zero-inits */#define MEM_POOL_REGION 0x0010u /* store pool in user-supplied region*/#define MEM_POOL_FILEMAPPING 0x0020u /* pool in user-supplied file mapping*/#define MEM_POOL_DEFAULT 0x8000u /* pool with default characteristics */

• 構造体へのリーバスエンジニアリングした後、何か気づいた– 簡単に攻略できる

– エラーハンドラへの関数ポインタ– 構造体とその要素の緩和策の欠如

– ヒープクッキー– チェックサム– しかし、 API （と MicroQuill社）の言い分は異なっている

SmartHeap の攻略

“SmartHeap はまた包括的なメモリーデバッグ API を持ち、 leakage 、 overwrite 、 double-free 、 wild pointer 、 out of memory 、以前に開放されたメモリへの参照およびその他のメモリーエラーを検出します。“

Error Debug ReleaseMEM_ALLOC_ZERO •MEM_BAD_BLOCK •MEM_BAD_FREE_BLOCK •MEM_BAD_BUFFER •MEM_BAD_FLAGS •MEM_BAD_HANDLE •MEM_BAD_POINTER •MEM_BAD_MEM_POOL •MEM_BLOCK_TOO_BIG •MEM_DOUBLE_FREE •MEM_EXCEEDED_CEILING •MEM_EXCEEDED_PROCESS_LIMIT •MEM_FREE_BLOCK_READ •MEM_FREE_BLOCK_WRITE •MEM_INTERNAL_ERROR •MEM_LEAKAGE •MEM_LOCK_ERROR •MEM_OUT_OF_BOUNDS_READ •MEM_OVERWRITE •MEM_UNDERWRITE •MEM_NOFREE •MEM_NOREALLOC •MEM_NOT_FIXED_SIZE •MEM_OUT_OF_MEMORY •MEM_READONLY_MODIFIED •MEM_RESIZE_FAILED •MEM_UNINITIALIZED_READ •MEM_UNINITIALIZED_WRITE •…

SmartHeap の攻略（続き）

今後の作業

• SmartHeap トリックを使用した経験に基づいた脆弱性解析– あまり時間がないため研究していない

• アセット固有のチャンクの解剖　– 非常に多いことは明らか

• OSX ランタイム上の Shockwave– インジェクションで OSX の例外ハンドラを書き換える

• Lingo スクリプト– Lingo のハンドリングによって脆弱性を探す

まとめ

• サマリ– 我々は文書化されていないメモリマネージャを含むシンボルのな

い大規模なコードベースで作業を開始し、文書化されていないファイル形式を解析した

– チームを組むことでどんな解析も楽になり、約 20 のゼロデイとツールを作成するに至った

• 我々はプロセスを示したかった　

– そして、初めから徹底的に問題に取り掛かることが重要– 頭痛回避– 適切に設計されていればこのツールは他のプロジェクトに流用

することができる

• 我々は Shockwave の解析に役立つものを発表したい– 我々の「 .idbs」– IDAPython スクリプトは「 iml32/dirapi」関数の名前変更する– 我々の x86 コードスタブ– コード中の最適な場所にインジェクションする– … もし何かあれば我々に聞いてください。

最後に

人材募集！

• この仕事に興味があるなら。。。– …Tippingpoint で働きたい : http://dvlabs.tippingpoint.com/team　– または、誰よりもゼロデイを見たい知りたい– aaron.portnoy at HP com にメールください

• 在宅勤務も可能– 米国テキサス州、オースティンがチームの拠点です。– 私は今ニューヨーク市で働いてします。

.

http://dvlabs.tippingpoint.com/team

Questions

Questions?

aaron.portnoylogan.p.brown

@ hp.com

謝辞

• チームコラボレーション– 本プレゼンテーションはチームで協力した成果です

– 我々のチームに感謝

• ブレーンストーミング、事実確認、スライドレビュー– Peter Silberman スライドレビュー– Rolf Rolles 私たちを間接的にサポート– busticati.org IRC ブレーンストーミングの場所を提供

shockwave のブラックボックス的監査 aaron portnoy and logan brown, tippingpoint dvlabs...

Documents