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/