No source? No problem! High speed binary fuzzing Nspace & - - PowerPoint PPT Presentation

no source no problem
SMART_READER_LITE
LIVE PREVIEW

No source? No problem! High speed binary fuzzing Nspace & - - PowerPoint PPT Presentation

No source? No problem! High speed binary fuzzing Nspace & @gannimo About this talk Fuzzing binaries is hard! Few tools, complex setup Fuzzing binaries in the kernel is even harder! New approach based on static rewriting High


slide-1
SLIDE 1

No source? No problem!

High speed binary fuzzing

Nspace & @gannimo

slide-2
SLIDE 2

2 High Speed Binary Fuzzing - HexHive - 36C3

About this talk

  • Fuzzing binaries is hard!
  • Few tools, complex setup
  • Fuzzing binaries in the kernel is even harder!
  • New approach based on static rewriting
slide-3
SLIDE 3

3 High Speed Binary Fuzzing - HexHive - 36C3

+ ≈ 100M LoC

Kernel Libc Desktop

slide-4
SLIDE 4

4 High Speed Binary Fuzzing - HexHive - 36C3

Fuzzing 101

Input generation OK Bug! Target

slide-5
SLIDE 5

5 High Speed Binary Fuzzing - HexHive - 36C3

Efgective fuzzing 101

  • Test cases must trigger bugs
  • Coverage-guided fuzzing
  • The fuzzer must detect bugs
  • Sanitization
  • Speed is key (zero sum game)!
slide-6
SLIDE 6

6 High Speed Binary Fuzzing - HexHive - 36C3

Fuzzing with source code

Source code Compiler Instrumented binary Coverage tracking, sanitization, ...

  • Add instrumentation at compile time
  • Short snippets of code for coverage tracking, sanitization, ...
slide-7
SLIDE 7

7 High Speed Binary Fuzzing - HexHive - 36C3

Application Application Libraries Kernel Drivers

Source No source

slide-8
SLIDE 8

8 High Speed Binary Fuzzing - HexHive - 36C3

Rewriting binaries

  • Approach 0: black box fuzzing
  • Approach 1: rewrite dynamically
  • Translate target at runtime
  • Terrible performance (10-100x slower)
  • Approach 2: rewrite statically
  • More complex analysis
  • ...but much better performance!
slide-9
SLIDE 9

9 High Speed Binary Fuzzing - HexHive - 36C3

Static rewriting challenges

  • Simply adding code breaks the target

mov [rax + rbx*8], rdi dec rbx jnz -7 mov [rax + rbx*8], rdi < n e w c

  • d

e > dec rbx jnz -7

  • Need to fjnd all references and adjust them
slide-10
SLIDE 10

10 High Speed Binary Fuzzing - HexHive - 36C3

Static rewriting challenges

  • Scalars and references are indistinguishable
  • Getting it wrong breaks the target

l

  • n

g ( * f

  • )

( l

  • n

g ) = & b a r ; m

  • v

[ r b p

  • x

8 ] , x 4 a a e l

  • n

g f

  • =

x 4 a a e ;

?

slide-11
SLIDE 11

11 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-12
SLIDE 12

12 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-13
SLIDE 13

13 High Speed Binary Fuzzing - HexHive - 36C3

RetroWrite [Oakland ‘20]

  • System for static binary instrumentation
  • Symbolized assembly fjles easy to instrument
  • Implements coverage tracking and binary ASan
slide-14
SLIDE 14

14 High Speed Binary Fuzzing - HexHive - 36C3

Position-independent code

  • Code that can be loaded at any address
  • Required for: ASLR, shared libraries
  • Cannot use hardcoded static addresses
  • Must use relative addressing instead
slide-15
SLIDE 15

15 High Speed Binary Fuzzing - HexHive - 36C3

Position-independent code

  • On x86_64, PIC leverages RIP-relative addressing
  • l

e a r a x , [ r i p + x 1 2 3 4 ]

  • Distinguish references from constants in PIE binaries
  • RIP-relative = reference, everything else = constant
slide-16
SLIDE 16

16 High Speed Binary Fuzzing - HexHive - 36C3

Symbolization

  • Symbolization replaces

references with assembler labels

lea rax, [rip + 0x1234] call 0x1337 dec rcx jnz -15

slide-17
SLIDE 17

17 High Speed Binary Fuzzing - HexHive - 36C3

Symbolization

  • Symbolization replaces

references with assembler labels

1) Relative jumps/calls

loop1: lea rax, [rip + 0x1234] call func1 dec rcx jnz loop1

slide-18
SLIDE 18

18 High Speed Binary Fuzzing - HexHive - 36C3

Symbolization

  • Symbolization replaces

references with assembler labels

1) Relative jumps/calls 2) PC-relative addresses

loop1: lea rax, [data1] call func1 dec rcx jnz loop1

slide-19
SLIDE 19

19 High Speed Binary Fuzzing - HexHive - 36C3

Symbolization

  • Symbolization replaces

references with assembler labels

1) Relative jumps/calls 2) PC-relative addresses 3) Data relocations

loop1: lea rax, [data1] call func1 dec rcx jnz loop1

slide-20
SLIDE 20

20 High Speed Binary Fuzzing - HexHive - 36C3

Symbolization

  • Symbolization replaces

references with assembler labels

1) Relative jumps/calls 2) PC-relative addresses 3) Data relocations

loop1: lea rax, [data1] < n e w c

  • d

e > call func1 dec rcx jnz loop1

slide-21
SLIDE 21

21 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-22
SLIDE 22

22 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing

input[0] == ‘P’ input[1] == ‘N’ input[2] == ‘G’ do_something() fail()

  • Record test coverage (e.g.

with instrumentation)

  • Inputs that trigger new

paths are “interesting”

  • Mutate interesting inputs to

discover new paths

slide-23
SLIDE 23

23 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing

https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html

slide-24
SLIDE 24

24 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-25
SLIDE 25

25 High Speed Binary Fuzzing - HexHive - 36C3

Address Sanitizer (ASan)

  • Instrumentation catches memory corruption at runtime
  • Arguably most dangerous class of bugs
  • Very popular sanitizer
  • Thousands of bugs in Chrome and Linux
  • About 2x slowdown
slide-26
SLIDE 26

26 High Speed Binary Fuzzing - HexHive - 36C3

ASan red zones

char buf[4]; buf Red zone Red zone strcpy(buf, “AAAAA”);

slide-27
SLIDE 27

27 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-28
SLIDE 28

28 High Speed Binary Fuzzing - HexHive - 36C3

RetroWrite instrumentation

  • Coverage tracking: instrument basic block starts
  • Binary ASan: instrument all memory accesses,

link with libASan

slide-29
SLIDE 29

29 High Speed Binary Fuzzing - HexHive - 36C3

Kernel vs. userspace fuzzing

Crash handling Tooling Determinism Userspace

OS handles crashes gracefully Easy to use and widely available Single-threaded code usually deterministic

Kernel

Need VM to keep the system stable More complex setup, fewer tools Interrupts, many concurrent threads

slide-30
SLIDE 30

30 High Speed Binary Fuzzing - HexHive - 36C3

Kernel binary fuzzing

  • Approach 0: black box fuzzing
  • Approach 1: dynamic translation
  • Slow! (10x +)
  • No sanitization like ASan
  • Approach 2: Intel Processor Trace (or similar)
  • Requires hardware support
  • Still no sanitization
  • Approach 3: static rewriting
slide-31
SLIDE 31

31 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite

  • Apply RetroWrite to the kernel
  • Implemented so far: support for Linux modules
  • Demonstrates that RetroWrite applies to the kernel
slide-32
SLIDE 32

32 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite

  • Kernel modules are always position-independent
  • Linux modules are ELF fjles
  • Reuse RetroWrite’s symbolizer
  • Implemented code coverage and binary ASan
slide-33
SLIDE 33

33 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite coverage

  • Idea: use kCov infrastructure
  • Can interoperate with source-based kCov
  • Call coverage collector at the start of each basic block
  • Integrates with, e.g., syzkaller, or debugfs
slide-34
SLIDE 34

34 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite coverage

cmp rbx, 1234 jz block1 mov [rax], rbx mov [rax], 1234

slide-35
SLIDE 35

35 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite coverage

c a l l t r a c e _ p c cmp rbx, 1234 jz block1 c a l l t r a c e _ p c mov [rax], rbx c a l l t r a c e _ p c mov [rax], 1234

slide-36
SLIDE 36

36 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite binary ASan

  • In userspace: link with libASan
  • In kernel: build kernel with KASan (kernel ASan)
  • Reuse modifjed userspace instrumentation pass
slide-37
SLIDE 37

37 High Speed Binary Fuzzing - HexHive - 36C3

kRetroWrite binary ASan

  • Instrument each memory access with a check
  • Failed checks print a bug report
  • Compatible with source-based kASan
slide-38
SLIDE 38

38 High Speed Binary Fuzzing - HexHive - 36C3

Fuzzing with kRetroWrite

  • Rewritten modules can be loaded and fuzzed with

standard kernel fuzzers

  • So far: tested with syzkaller
slide-39
SLIDE 39

39 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-40
SLIDE 40

40 High Speed Binary Fuzzing - HexHive - 36C3

Our experiments

  • Userspace: SPEC2006 runtime performance
  • RetroWrite ASan
  • Source ASan
  • Valgrind memcheck
  • Kernel: fuzz fjlesystems/drivers with syzkaller
  • Source KASan + kCov
  • kRetroWrite KASan + kCov
slide-41
SLIDE 41

41 High Speed Binary Fuzzing - HexHive - 36C3

Results - Userspace

slide-42
SLIDE 42

42 High Speed Binary Fuzzing - HexHive - 36C3

Preliminary results - kernel

Exec/s - BTRFS Source kRetroWrite

slide-43
SLIDE 43

Demo

slide-44
SLIDE 44

44 High Speed Binary Fuzzing - HexHive - 36C3

Let’s test kRetroWrite on a fjlesystem

slide-45
SLIDE 45

45 High Speed Binary Fuzzing - HexHive - 36C3

Coverage-guided fuzzing Sanitization Instrumenting binaries in the kernel Instrumenting binaries

slide-46
SLIDE 46

46 High Speed Binary Fuzzing - HexHive - 36C3

Conclusions

  • Instrument real-world binaries for fuzzing
  • Coverage tracking for fast fuzzing
  • Memory checking to detect bugs
  • Static rewriting at zero instrumentation cost
  • Limited to position independent code
  • Symbolize without heuristics
  • More? https://github.com/HexHive/retrowrite
  • User-space now, kernel in ~2-3 weeks