PacSec2015 slides

1. ハイパフォーマンス・ファジング
Richard Johnson | PacSec 2015

2. はじめに
自己紹介
→Richard Johnson / @richinseattle
→Research Manager, Vulnerability Development
→Cisco, Talos Security Intelligence and Research Group
アジェンダ
→なぜパフォーマンスが重要か
→ターゲットと入力の選定
→エンジンのデザイン
→ホストの設定

3. なぜパフォーマンスが重要か

4. なぜパフォーマンスが重要か
突然変異型のファジングはたいてい簡単にみえる
→ただし、問題発生時にハードウェア例外
CPUサイクルの大半が無駄になっている
→プログラムのロード時間 対 ファイルのパース時間
→ファジングには高I/O、ブロッキングCPUが必要
→巨大ファイルでの突然変異は非効率的
ファザーの設計を定性的に分析
ファザーの戦略を定性的にに分析

5. Microsoft SDL 検証ガイドライン
ファジングはSDLC検証において必須要件
「コードのパースにおいて入力が信頼境界を越えている可能性が
ある場合には、そのコードにおいてファイルファジングを行う必
要があります。セキュリティ開発ライフサイクル(SDL)のバグバー
で説明しているように、全ての問題点が修正されなければなりま
せん。推奨されるツールによって、全てのファイルパーサーが
ファジングされる必要があります。」
https://msdn.microsoft.com/en-us/library/windows/desktop/cc307418.asp

6. Microsoft SDL 検証ガイドライン
ファジングはSDL検証において必須要件
「Win32/64/Mac: 最適化されたテンプレートのセット
を使う必要があります。テンプレートの最適化は最小
のテンプレートによるパーサのコードカバレッジの最
大数の総量に基づいています。最適化されたテンプ
レートはファジングの有効性を倍増させることが研究
で示されています。SDLバグバーでは、最後のバグが見
つかり修正されてから、最小の50万の反復、少なくと
も 25 万 の 反 復 の フ ァ ジ ン グ が 見 ら れ ま す 。 」
https://msdn.microsoft.com/en-us/library/windows/desktop/cc307418.asp

7. Microsoft SDL 検証ガイドライン
ファジングを必須にすることは良いこと
どのように調整したか?
→反復は現実的なリソースによって制限される
→複雑なパーサーはより多くのリソースを必要とする
→反復はガイダンスの定義においてはよくない選択肢
どのような属性が利用可能なリソースでの理論的
な限界を決定するのか
ファジングの有効性を最適化するベストプラク
ティスは何か

8. 過去のパフォーマンス統計
Microsoft Windows Vista 2006
→3.5億の反復、250以上のファイルパーサー
l~ パーサーあたり140万の反復(平均)
→300超の問題が修正 (1バグあたり 116万のテスト)
Microsoft Office 2010
→8億の反復、400のファイルパーサー
→1800のバグが修正 (1バグあたり44444のテスト)
•http://blogs.technet.com/b/office2010/archive/2010/05/11/how-the-sdl-helped-improve-security-in-office-
2010.aspx
チャーリー・ミラー 2010
→700万の反復、4パーサー
•~ パーサーあたり180万の反復 (平均)
→320 - 470 のクラッシュ (1バグあたり14893 - 21875のテスト)

9. 過去のパフォーマンス統計 (cmiller)
チャーリー・ミラーは意図的に悪いデザインで行った
→入力を変異させる5行のPython
→システムハンドラでファイルを反復するAppleScript
→Microsoft minifuzz も同様に愚直である
入力の選択
→コードカバレッジの最小セットによって8万のPDFが1515に減少
入力 ソフトウェア 数 平均時間
PDF Adobe Reader 9.2.0 3M 5.35s
PDF Apple Preview (OS X 10.6.1) 2.8M 7.68s
PPT OpenOffice Impress 3.3.1 610k 32s+
PPT MSOffice PowerPoint 2008 Mac 595k 32s

10. ターゲットと入力の選定

11. ターゲットの選定
64-bit 対 32-bit アプリケーション (x86 アーキテクチャ)
→64-bitバイナリは32-bitよりサイズが肥大
→64-bitランタイムのメモリ使用量は32ビットより多い
→64-bit OSはVMのためにより多くのメモリとディスクを消費
→いくつかのソフトウェアは32-bitバイナリのみ
→いくつかのファザーとデバッガは32-bitのみをサポート
→64-bit CPUは性能向上のためにより多くのレジスタを持つ
•最適化はコンパイラに依存

12. ターゲットの選定
64-bitプログラムは高速か?
→x64上では? 小さいながらも変化がある
•Chrome – 無視できる程度
–http://www.7tutorials.com/google-chrome-64-bit-it-better-32-bit-version
•Photoshop – イエス?
–8-12% (無関係なディスクI/Oの最適化に関するトーク)
–https://helpx.adobe.com/photoshop/kb/64-bit-os-benefits-limitations.html
→SPARC上では? ノー
•True story, but who cares
–http://www.osnews.com/story/5768/Are_64-bit_Binaries_Really_Slower_than_32-bit_Binaries_/page3/

13. ターゲットの選定
はるかに重要: コード行を最小限に
→プログラムを初期化し実際にパーサーコードの実行
に費やされる時間の比率
最適化の戦略
→ターゲットライブラリのディレクトリ
→APIごとに薄いラッパーを書く
•機能ごとにターゲットとする
→高コストなチェックサム/圧縮を除くパッチを書く
•Flayerが詳しい (Drewery & Ormandy WOOT'07)
→ターゲットをメモリ内でファジングできるよう設計

14. 入力の選定
入力は数値セット
入力パーサはステートマシンである(べき)
→FSMによって記述された仕様
→通常、パーサコードは現実にはFSMでは実装されていない
→ハイパフォーマンスなFSMパーサにはLangSecのペーパー
•http://www.cs.dartmouth.edu/~pete/pubs/LangSec-2014-fsm-parsers.pdf
ゴール: 空間の検索と新しい遷移の発見
個別の検索は計算コストが高い
→我々は時間のために最適化が必要

15. 入力の選定
入力の選定の最適化
→ファイルサイズは非常に重要
•小さい入力サイズでは変異はより意味がある
•小さい入力は読み込みとパースがより高速
•いくつかのテスト生成方法は入力バイト当たりのメモリを大量
に使用する
→入力に応じた特徴セットにより対象へフォーカス可能
•手作りまたは最小化されたサンプル
•ファジングのフィードバックやconclic testは異なる機能を持
つ固有の小さな入力の生成を自動化する

16. 入力の選定
CMU 変形
→Optimizing Seed Selection for Fuzzing – USENIX 2014
•https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-rebert.pdf
→最小セットは期待ほど役に立たない
→重みなしの最小セットが勝ち
→結論: 最小セットは壊れていなければ良好
•Peach minset toolはアルゴリズムの最小セットではない
•Peach minsetはランダム選定と同等に機能する
もう少しカバレッジトレーサーの性能について解説…

17. エンジンのデザイン

18. エンジンのデザイン
新しい入力の生成
新しい入力でターゲットを実行
障害状態の検出

19. エンジンのデザイン
新しい入力の生成
新しい入力でターゲットを実行
ターゲットの実行をトレース
トレースの出力をモニター
障害状態の検出
障害ではない状態の検出

20. 入力の生成
もっとも重要なのはミューテータの選定
→AFL
Deterministic bitflip
1, 2, 4, 8, 16, 32 bits
Deterministic addition/subtraction
Values { 1 – 35 } for each byte, short, word, dword
Little endian and big endian
Deterministic 'interesting' constant values
27 boundary values
Dictionary keywords
Havoc
Random bitflips, arithmetic, block move/copy, truncate
Splice
Merge two previously generated inputs

21. 入力の生成
最も重要なのはミューテータの選定
→Radamsa
ab: enhance silly issues in ASCII string data handling
bd: drop a byte
bf: flip one bit
bi: insert a random byte
br: repeat a byte
bp: permute some bytes
bei: increment a byte by one
bed: decrement a byte by one
ber: swap a byte with a random one
sr: repeat a sequence of bytes
sd: delete a sequence of bytes
ld: delete a line

22. 入力の生成
最も重要なのはミューテータの選定
→Radamsa
lds: delete many lines
lr2: duplicate a line
li: copy a line closeby
lr: repeat a line
ls: swap two lines
lp: swap order of lines
lis: insert a line from elsewhere
lrs: replace a line with one from elsewhere
td: delete a node
tr2: duplicate a node
ts1: swap one node with another one
ts2: swap two nodes pairwise

23. 入力の生成
最も重要なのはミューテータの選定
→Radamsa
tr: repeat a path of the parse tree
uw: try to make a code point too wide
ui: insert funny unicode
num: try to modify a textual number
xp: try to parse XML and mutate it
ft: jump to a similar position in block
fn: likely clone data between similar positions
fo: fuse previously seen data elsewhere
Mutation patterns (-p)
od: Mutate once
nd: Mutate possibly many times
bu: Make several mutations closeby once

24. 入力の生成
決定性ミューテータが最初
並べ替えと無限のランダムモード
現実的なレベルに順列をスタック
新しいミューテータの有効性の評価のために
フィードバックループが必要

25. ターゲットの実行
実行ループの使用は遅い
→プロセス生成、リンク、初期化
fork() サーバを使用
→初期化のスキップ
→Copy-on-writeによるプロセス複製はLinuxでは高速
→WindowsとOSXではプロセスメモリを手動コピー
•COWページより30倍以上のパフォーマンス向上

26. ターゲットの実行
Windows黒魔術のSUA posix fork() の余談
→ZwCreateProcess (NULL, …) – Windows 2000
•セクション、スレッド、CSRSS、User32その他がない
→RtlCloneUserProcess – Windows Vista
•限定的な範囲で動作
•アプリケーションはWin32 APIを使えない
→RtlCreateProcessReflection - Windows 7
•速やかなフルメモリダンプ生成のために設計
•スレッドに復元できない
Windows 10 fork...

27. ターゲットの実行
fork、ふざけてるの??
linux
10000 fork()
0.763s → 13106 exec/sec
10000 fork/exec(/bin/false)
2.761s → 3621 exec/sec
10000 fork/exec(/bin/false) w/ taskset
2.073s → 4823 exec/sec
cygwin
10000 fork()
29.954s → 333 exec/sec
10000 fork/exec(/bin/false)
63.898s → 156 exec/sec
RtlCloneUserProcess (older hardware)
10000 fork()
17.457s → 574 exec/sec
ZwCreateUserProcess
...

28. Forkのデモ

29. ターゲットの実行のトレース
フィードバックループファジングは最終的にはAFLで実現
→ファジング方針の定性的評価を可能に
→計装方針の最適化
→フィードバックシグナルの最適化
→ソースコードのみ**
以前のバイナリフィードバックする方法では遅すぎた
→EFSは過度に複雑でありPaiMeiを使用した
→BCCFはCOSEINCコードカバレッジPintoolを使用
→HonggfuzzはBTSを使用

30. ターゲットの実行のトレース
フックするエンジンの選定は重要
→Pin / DynamoRIO は遅い
•** ブロックカバレッジでは5から10倍は遅くなる
•フォークサーバのほうが利点がある
TurboTrace:
1. LD_PRELOADされたライブラリから自身をfork.
2. フォークされた子をptrace.
3. _startでbreak on
4. fork()の繰り返しを行うことになる実際の関数をインジェクト.
5. callを経由.
6. _startを修正し実行を継続.

31. TurboTracer デモ

32. ターゲット実行のトレース
フックするエンジンの選定は重要
→TurboTraceパフォーマンス, 100回の繰り返し
•20 – 50% スピードが向上
First test (without pintool, just instrumentation):
Pin without pintool on test_png : 55.03 seconds
Turbotrace without pintool on test_png : 37.24 seconds
Second test (bblocks pintool):
Pin bblocks pintool on test_png : 72.62 seconds
Turbotrace bblocks pintool on test_png : 51.07 seconds
Second test (calltrace pintool):
Pin calltrace pintool on test_png : 106.19 seconds
Turbotrace calltrace pintool on test_png : 85.24 seconds

33. ターゲット実行のトレース
フックするエンジンの選定は重要
→QEMU
•QEMUによるユーザーランドのブロッキングトレース
•スタティックにコンパイルされたバイナリ
•Linuxのみ
•Readpng: ~860 ex/s vs ~3800 afl-gcc – 4.5倍低速
→DynInst
•スタティックなバイナリ書き換え
•ダイナミックにコンパイルされたバイナリ
•現在はLinuxのみ (windowsへのポーティング中)
•Readpng: ~2400 ex/s vs ~3300 afl-gcc – 1.3倍低速

34. AFL-DYNINST デモ

35. トレース出力のモニター
ロギングは重要。トレーサーは大量にI/Oを処理
→フィードバックシグナルに十分なものだけを保存
ブロックカバレッジは弱く、エッジ遷移がよい
シェアードメモリの使用
cur_location = (block_address >> 4) ^ (block_address << 8);
shared_mem[cur_location ^ prev_location]++;
prev_location = cur_location >> 1;

36. 障害/非障害の検出
障害
→Linux
•#define WTERMSIG(status) ((status) & 0x7f)
→Windows
•デバッガーが唯一の選択肢
非障害
→タイムアウト
•自身の調整
•最低限のタイムアウト,
→CPU使用量
•Xミリ秒でCPU使用率が0付近まで落ちた場合

37. ホストの設定

38. システムキャッシュ
Windows
→Windows 7以前ではファイルシステムのキャッシュは
8MBのみ
•HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥Sessio
n Manager¥Memory Management
•LargeSystemCache = 1に値を設定
→ディスクのプロパティにて書込みキャッシュが有効化

39. システムキャッシュ
Linux
→デフォルトで大容量システムキャッシュが有効
→/sbin/hdparm -W 1 /dev/hda 書込みキャッシュの有効化
→$ sysctl -a | grep dirty
•vm.dirty_background_ratio = 10
•vm.dirty_background_bytes = 0
•vm.dirty_ratio = 20
•vm.dirty_bytes = 0
•vm.dirty_writeback_centisecs = 500
•vm.dirty_expire_centisecs = 3000

40. ストレージ: HDD
~100 MB/s
キャッシュはプログラムから積極的に使われる
→Windows Superfetch (デフォルト)
→Linux Preload
•http://techthrob.com/tech/preload_files/graph.png
その機能は低メモリしか使えないシナリオでもっ
とも有用
→通常、ファジングではVMごとに1-2GBのメモリ

41. ストレージ: HDD
ソリッドステイトUSBドライブのキャッシュ利用
→利点は低レンテンシー、広帯域ではない
→Windows ReadyBoost (デフォルトで利用可能)
•フラッシュでのランダムアクセスはHDDの10倍高速
•http://www.7tutorials.com/files/img/readyboost_performance/readyboost_performance14.png
•まだキャッシュ用にデバイスを使っておらず、新しいデバイ
スが256MBから32GBのサイズで、4KBのランダム読込みで
2.5MB/s以上の転送速度、512KBのランダム書込みで1.75MB/s
以上の転送速度のとき
–https://technet.microsoft.com/en-us/magazine/2007.03.vistakernel.aspx
→Linux >3.10 bache / zfs l2arc
•12.2K ランダム io/sec -> 18.5K/sec with bcache, 50% の増加
–http://bcache.evilpiepirate.org/

42. ホストの設定
Standard HDD Raid 0

43. ストレージ: SSD
HDDを上回る主要なパフォーマンスの向上
Raid 0 SSD

44. ストレージ: Ram Disk
SSDより高速、フラグメ
ントの排除
→http://superuser.com/questions/686378/can-ssd-raid-be-
faster-than-ramdisk (10GB/s - 17GB/s)
Linux - 内蔵
→ramfsまたはtmpfs
Windows - 3rd party
→差異が大きい
•https://www.raymond.cc/blog/12-ram-disk-
software-benchmarked-for-fastest-read-and-write-
speed/
→SoftPerfect RamDiskが
フリーソフトウェアで秀逸
•https://www.softperfect.com/products/ramdisk/

45. ホストの設定
SSD Ramdisk

46. メモリー
32-bit メモリーの限界
→Linux – PAEカーネルへの組み込み
→Windows
•OSのエディションによる制限
•ドライバの互換性が犠牲にされた根拠
–http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
•カーネルパッチが必須
–http://www.geoffchappell.com/notes/windows/license/memory.htm
–http://news.saferbytes.it/analisi/2012/08/x86-4gb-memory-limit-from-a-technical-perspective/
–http://news.saferbytes.it/analisi/2013/02/saferbytes-x86-memory-bootkit-new-updated-build-is-out/

47. まとめ

48. Cisco Talos VulnDev Team
→Richard Johnson
•rjohnson@sourcefire.com
•@richinseattle
→Marcin Noga
→Yves Younan
→Piotr Bania
→Aleksandar Nikolic
→Ali Rizvi-Santiago
Thank You!