XPDDS17: Using American Fuzzy Lop on the x86 Instruction Emulator - George Dunlap, Citrix
-
Upload
the-linux-foundation -
Category
Technology
-
view
217 -
download
0
Transcript of XPDDS17: Using American Fuzzy Lop on the x86 Instruction Emulator - George Dunlap, Citrix
Finding Bugs with
American Fuzzy LopGeorge Dunlap
American Fuzzy Lop
American Fuzzy Lop
Instrumentation-guided genetic fuzzer
Goals
• Tell you about AFL (because it’s cool)
• To encourage you to look into using AFL
• In your own test cases…
• …or in Xen
Outline
• AFL overview
• Using AFL for the Xen x86 instruction emulator
• Other opportunities for fuzzing in Xen
AFL: Basic Idea
• Start with a set of “interesting” test cases
• Run them through an instrumented binary to see what paths are taken
• Take one off the list and start mutating it
• New path taken? Add it to your list of “interesting” test cases
• Crash? Keep it in a separate file
x86_emulate• Common code to decode and emulate x86 instructions
• Over 8000 LoC
• Called from HVM, PV, and shadow code
• Pass it:
• CPU context, callbacks for all other state interaction
• 26 callbacks; most are optional, all can return failure
• Already has a user-space test harness
x86_decode (single instruction)
x86_emulate single instruction, blank cpu slate,
minimal set of callbacks
x86_emulate multiple instructions
FPU Exceptions• FPU instructions re-executed in the hypervisor context
• Xen has framework for handling exceptions, properly; AFL framework didn’t
• FPU exceptions don’t happen unless they’re enabled, and they start off disabled
• …so AFL had figured out how to turn them on
• Hack: Disable exceptions after every instruction iteration
Fuzz the core registers
XSA-195: BT* instructions
Allowing AFL to fuzz more
• Implement more callbacks
• Allow reads to return fuzzed values (rather than zero)
• Allow more complete cpu state to be fuzzed
• Allow non-canonical addresses
• Allow random failure of callbacks
A bug in one of the XSA fixes!
(Valid) assertions about architecturally correct state
Unchecked return value
Unreal mode
So AFL…• Discovered three critical bugs in x86_emulate
• Discovered…
• How to turn on FPU exceptions
• Assumptions about architectural consistency
• An unchecked return value
• Assumptions about unreal mode
AFL in xen.git
Running afl-harness• Install AFL
• afl packages in debian-testing, others
• d/l and build from http://lcamtuf.coredump.cx/afl/
• Build afl-harness
• cd xen.git/tools/fuzz/x86_instruction_emulator
• make CC=afl-gcc afl
• Make starting input
• dd if=/dev/urandom of=input/rand bs=$(./afl-harness --min-input)
• Run afl-fuzz
• afl-fuzz -i input/ -o output/ -- ./afl-harness
Diving deeper
• “Map” and the branch path
• Fork server / “persistent mode”
• Other languages
• Python, Go, Rust, ocaml, GJC Java
• Running in parallel
Fuzzing more• Already fuzz libelf
• Xen hypercall interface
• GSOC student working on this
• xenstore?
• pygrub?
• disk / network backends?
A request for help…
• oss-fuzz
• A Google fuzzing project
• Requires someone to sign a contributor agreement
Goal To convince you to look into using
AFL on your code
Questions
• http://lcamtuf.coredump.cx/afl/