Browser Fuzzing with a Twist (and a Shake) -- ZeroNights 2015

Browser Fuzzing with a Twist (and a Shake)

Jeremy Brown, 2015

Agenda

I. IntroductionI. Target ArchitectureII. Infrastructure Notes

II. ShakeItI. Current ToolingII. InternalsIII. Incubation Results

III. Conclusion

#whoami

• Jeremy Brown– Independent researcher / consultant– Formerly of Microsoft• Windows/Phone/Xbox Security• Malware Protection Center

– Also, Tenable• Nessus• RE patches

What I’m not covering

• Comprehensive browser fundamentals– Just enough to get your feet wet

• Looking for bugs outside of rendering engines– There’s plenty of other attack surface, but this one

is really juicy & often no user interaction required• Sandbox escapes– This is needed post-compromise of renderer

What I’m covering

• The fuzzing engine part of the puzzle– But ShakeIt is not a fuzzer, it is a mutator

• Working with grammar-based parsing engines– Not specific to browsers, but they’re a primary

target• Overall setup you need to do so effectively– But not claiming I fuzz as well as Ben Nagy– A lot of hard lessons learned

Why

• Share the research instead of just letting it sit on my box– Projects often fade away after incubation, but are

more valuable in collaboration• Not many talks detail the process and how the

engine actually works– Most engines are not rocket science– Fuzzing really has no rules, any method fair game

Attack Surface Overview

Credit:Chris Rolf / LeafSR (now Yahoo!)

http://blog.leafsr.com/2012/09/09/google-native-client-attack-surface-and-vulnerabilities-part-4/

Reference:“Inside Adobe Reader Protected Mode - Part 1 - Design” – Security @ Adobe

http://blogs.adobe.com/security/2010/10/inside-adobe-reader-protected-mode-part-1-design.html

Fuzzing Options

• Generation

Reference: http://www.peachfuzzer.com

Fuzzing Options

• Mutation– Zzuf is the canonical example here

Reference: http://caca.zoy.org/wiki/zzuf

Fuzzing Options

• Code-assisted (eg. sub-evolutionary)– American Fuzzy Lop

Reference: http://lcamtuf.coredump.cx/afl/

Fuzzing Options

Reference: http://lcamtuf.coredump.cx/afl/

Infrastructure

Pieces to the Puzzle

• A complete fuzzing framework has– Fuzzing Engine– System Harnesses– Scaling Infrastructure– Target-specific Support– Helpers


• Fuzzing Engine– Generator per specifications– Mutator based on particular algorithms– Instrumentation for code-assisted fuzzing


• Local System Harnesses– Debug harness to catch crashes– Filesystem monitor for interesting read/write– Dedicated and high performance database server• Or SSD for fast access to local sqlite db


• Scaling Infrastructure– High-performance machines with hypervisors– Clusters in a master/slave setup– An Army of Droids (eg. jduck)– Utilizing the online cloud providers


• Target-specific Support– File store for templates (eg. html, xml, pdf)• Client to add new templates / remove bad ones

• WinAppDbg– Great framework, very versatile– Provides a ton of options for instrumentation– Run into interesting issues sometimes, eg.

bottleneck with db server / attach memory errors


• Helpers– Pause/Restart support– Automatic repro / PoC generation– Data failure backup mechanisms– Minset support– Instrumentation / Code Coverage

Agenda



III. Conclusion

Current Tooling

• Cross_fuzz– Cross-document DOM binding fuzzer by lcamtuf– Similar concept to ShakeIt as it either selects or

reuses input fragments• Fuzzinator– Tokenizes a collection of input and builds new

tests from those

References:http://lcamtuf.coredump.cx/cross_fuzz/

http://browser.sed.hu/blog/20141023/fuzzinator-reloaded

Current Tooling

• Jsfunfuzz– JavaScript fuzzer from Jesse Ruderman– Uses generational method to create interesting JS

• LangFuzz– Grammar-based fuzzer by Mozilla / Saarland Uni– Utilizes the ANTLR suite for parsing– Like Cross_fuzz, it can reuse input fragments

References: https://github.com/MozillaSecurity/funfuzz/blob/master/js/jsfunfuzz/README.md

https://www.st.cs.uni-saarland.de/publications/files/holler-usenix-2012.pdf

Deviations from ShakeIt

• Dictionary– Defining a dictionary of valid tokens and replacing

them with either randomly generated or oracle input

• Nesting– Duplicating or multiplying tokens to create nesting

in random or strategic locations

ShakeIt Algorithm

High-level Diagram

How it works

• Collection of tokens or “changeables”– Data– Position

• Switch the data a random positions• Fix it all back up and generate new test case• Idea is simple, but implementation is more

complex

Process

• Step 1– Feed it templates (HTML, XML, JS, PDF + JS, etc)– Can handle simple or complex input

Implementation Details

• Consume template– Modes for HTML/JS or PDF/JS

• Call Shake.It– It calls Token.Find to find all the tokens– We need at least (2) to perform mutation– Token.Find uses extensive set of regex’s


• Token.Match successful, save it and continue• Once complete, Shake.Shuffle all the tokens– Iterate from the end, choosing random index and

removing items from the pool until exhaustion


• After Shuffle, now build out the mutation– Find each shuffled position, insert new data and

append all other template content appropriately


• Write to output and repeat n iterations!– We use .NET threads to utilize computing power– SHA1 for *unique filenames

• * We don’t care about collisions here

Example Template

Fuzzing Strategy

• Tries to “confuse” the rendering engine• Mixes types, parameters, values, objects• Tries to put the browser in a weird state and

force it to make bad decisions– “Shaking the memory corruption tree”

Mutated Examples

Process

• Step 2– Store mutated collection on file or web server– Make it accessible to a browser

Process

• Step 3– Setup target with harness, iterate over collection– Store results in database for sorting, repros on

network share for debugging promising crashes

Implementation

• Written in C#– Algorithm is portable though

• Available after this talk

Incubation

Incubation Results

• Interesting Chrome/Opera crashes– Sadly hard to save repros per infrastructure issues– Could not determine if crashes can from render

bugs or attach/synchronization issues

Incubation Results

• Multiple crashes in WebKit/GTK+– Only 2 / 4 repro’d– Suspected invalid access on garbage collection

Incubation Results

• Unremarkable crash in KHTML– Continuous memory allocations and copies

Incubation Results

• Likely exploitable memory corruption bug in Netsurf (popular embedded device browser)– Corruption of internal structure pointer– Triggered by mutated tag property

Incubation Results

• Interesting crash in Phonon (VLC @ web)– Triggered by parsing multimedia content / tags

Challenges / Lessons Learned

• Comprehensive fuzzing harnesses enable a smooth process

• Without a complete system, it’s tough to be successful– Bandwidth, resources or tooling are bottlenecks

Agenda



III. Conclusion

Future Work

• Enable ShakeIt in scalable environment OR• Port it to existing fuzzing frameworks– Joxean’s Nightmare Fuzzer– <insert your custom fuzzing framework @ home>– Perhaps even a Metasploit auxiliary module

Conclusion

• Fuzzing is more than a mutation engine– Strategy and infrastructure matter too

• Investment in tooling is paramount– But don’t micro-manage ROI!

• More complexity == more fuzzing bugs– Code review for complex operations is expensive– Manually pen-testing is great for logic bugs– Does anyone seeing software becoming simpler?

Conclusion

• Sandboxes cannot save you from bugs– You just need +1 more bug

• SDL cannot save you from bugs– Too much old code, too much new code, not

enough eyes or interested people to throw at it• Mitigations cannot save you from bugs– They only make them +n days harder to exploit

• Managed code is a positive step forward

The End

Questions?

Technology

Browser Fuzzing with a Twist (and a Shake) -- ZeroNights 2015