Download as PDF, PPTX
![トレース出力のモニター
ロギングは重要。トレーサーは大量にI/Oを処理
→フィードバックシグナルに十分なものだけを保存
ブロックカバレッジは弱く、エッジ遷移がよい
シェアードメモリの使用
cur_location = (block_address >> 4) ^ (block_address << 8);
shared_mem[cur_location ^ prev_location]++;
prev_location = cur_location >> 1;](https://image.slidesharecdn.com/richardhighperformancefuzzing-ja-151211124301/85/Richard-high-performance-fuzzing-ja-35-320.jpg)
More Related Content
Similar to Richard high performance fuzzing ja
Richard high performance fuzzing ja
- 1. ハイパフォーマンス・ファジング Richard Johnson |PacSec 2015
- 2. はじめに 自己紹介 →Richard Johnson /@richinseattle →Research Manager, Vulnerability Development →Cisco, Talos Security Intelligence and Research Group アジェンダ →なぜパフォーマンスが重要か →ターゲットと入力の選定 →エンジンのデザイン →ホストの設定
- 3.
- 4.
- 5.
- 6. Microsoft SDL 検証ガイドライン ファジングはSDL検証において必須要件 「Win32/64/Mac:最適化されたテンプレートのセット を使う必要があります。テンプレートの最適化は最小 のテンプレートによるパーサのコードカバレッジの最 大数の総量に基づいています。最適化されたテンプ レートはファジングの有効性を倍増させることが研究 で示されています。SDLバグバーでは、最後のバグが見 つかり修正されてから、最小の50万の反復、少なくと も 25 万 の 反 復 の フ ァ ジ ン グ が 見 ら れ ま す 。 」 https://msdn.microsoft.com/en-us/library/windows/desktop/cc307418.asp
- 7.
- 8. 過去のパフォーマンス統計 Microsoft Windows Vista2006 →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.
- 15.
- 16. 入力の選定 CMU 変形 →Optimizing SeedSelection 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 sillyissues 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 manylines 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 apath 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.
- 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.
- 29.
- 30. ターゲットの実行のトレース フックするエンジンの選定は重要 →Pin / DynamoRIOは遅い •** ブロックカバレッジでは5から10倍は遅くなる •フォークサーバのほうが利点がある TurboTrace: 1. LD_PRELOADされたライブラリから自身をfork. 2. フォークされた子をptrace. 3. _startでbreak on 4. fork()の繰り返しを行うことになる実際の関数をインジェクト. 5. callを経由. 6. _startを修正し実行を継続.
- 31.
- 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/svs ~3800 afl-gcc – 4.5倍低速 →DynInst •スタティックなバイナリ書き換え •ダイナミックにコンパイルされたバイナリ •現在はLinuxのみ (windowsへのポーティング中) •Readpng: ~2400 ex/s vs ~3300 afl-gcc – 1.3倍低速
- 34.
- 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¥MemoryManagement •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 キャッシュはプログラムから積極的に使われる →WindowsSuperfetch (デフォルト) →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.
- 43.
- 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.
- 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 VulnDevTeam →Richard Johnson •rjohnson@sourcefire.com •@richinseattle →Marcin Noga →Yves Younan →Piotr Bania →Aleksandar Nikolic →Ali Rizvi-Santiago Thank You!