3. Fuzzing
• Mainly applicable to
packages that parse complex
inputs
• Technique of testing software
by continuously feeding it
automatically mutated inputs
• Hardening systems that parse
inputs from potentially
malicious users
4. What to Fuzz
• Image decoders
• Format string decoders
• SIP message decoders
• E-mail
• HTTP requests
• XML
• JSON
• Anything that has user inputs
5. Fuzzing
• American Fuzzy Lop
• Throwing random things at
your code isn’t effective
• Compile time instrumentation
and genetic algorithms
• Instrumented source
coverage to judge which
mutations pushed the
program into new paths,
eventually hitting many
rarely-tested branches
http://lcamtuf.coredump.cx/afl/
http://lcamtuf.coredump.cx/afl/README.txt
6. Fuzzing Flow
1. Load user-supplied initial test cases into the queue,
2. Take next input file from the queue,
3. Attempt to trim the test case to the smallest size that doesn't alter
the measured behavior of the program,
4. Repeatedly mutate the file using a balanced and well-researched
variety of traditional fuzzing strategies,
5. If any of the generated mutations resulted in a new state transition
recorded by the instrumentation, add mutated output as a new
entry in the queue.
6. Go to 2.
7. Go-Fuzz
• Based on American Fuzzy Lop
• Instruments the source by rewriting it
• Catches
• Index out of range
• Panics
• Deadlock
• Insane memory allocation
• Anything else you explicitly check
for
https://github.com/dvyukov/go-fuzz
8. Go Fuzz
• You provide
• an entry function for go-fuzz
• Fuzz(data []byte) int
• 0 on error
• 1 if input was interesting
• -1 if not interesting
• initial set of inputs
• compile your program with go-
fuzz-build
