DrFuzz SecDev 2016

Using Dr. Fuzz, Dr.
Memory, and
Custom Dynamic Tools for Secure
Development
Derek Bruening bruening@google.com

Qin Zhao zhaoqin@google.com
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Fuzz Framework
● Dr. Memory
● DynamoRIO
● Conclusion
2
Introduction
● DynamoRIO
● A dynamic binary instrumentation framework
■ Windows, Linux, Android
■ IA-32, AMD64, ARM, AArch64
● Custom tools
■ Dr. Memory, drstrace, drltrace, drcachesim, drcov, etc.
● Dr. Memory
● A memory checking tool build on top of DynamoRIO
● Dr. Fuzz
● Dr. Fuzz tool
■ Dr. Memory fuzz testing mode
● Dr. Fuzz framework
■ DynamoRIO fuzz testing extension
3
DynamoRIO
application code basic

block
foo() bar() cache
A
A A
C
B C
DynamoRIO D
D
4
DynamoRIO + Client
transformation time execution time:

e.g., code coverage e.g., dynamic instr count

client code
block
foo() bar() cache
A’
A
A’
C’
B C
DynamoRIO D’
D
5
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Conclusion
6
Dr. Fuzz Tool
● Fuzzing Test
● Generate (random) input data
● Discover coding errors and security vulnerabilities
● Dr. Fuzz Tool
● Dr. Memory Fuzz Testing Mode
■ Dr. Memory: a memory checking tool
■ In-process function-level fuzzing
■ Feedback guided fuzzing
■ Customizable input generation
● Dr. Fuzz vs LibFuzzer
7
Dr. Fuzz Tool Outline
● Fuzzing Test
● Dr. Fuzz Tool
8
Dr. Memory: A Memory Checking Tool
● Memory Checking Tools

● Instrument applications with error checking code
■ Compiler: Address/Memory/Thread Sanitizer
■ Dynamic Binary Instrumentation: Dr. Memory, Valgrind, Purify
● Discover more bugs than just those leading to a visible crash
● Report errors earlier than a crash
● Dr. Memory
● Detects a variety of memory errors
■ Unaddressable bugs
■ Uninitialized read
■ Double free, handle/memory leaks, etc.
● 10x slowdown for “full mode”, 3x for “light mode”
9
Dr. Memory: A Memory Checking Tool
● Demo
10
● Fuzzing Test
● Dr. Fuzz Tool
11
In-process Function-level Fuzzing

Dr. Fuzz
block
foo() bar() cache
A
A
F
E
C
B C
DynamoRIO D
D
pre_func()
E E
F post_func()
F
12
● In-process Fuzzing
● Run init/finit code only once
● Amortizing code cache building cost
■ Building code cache is expensive in Dr. Memory
● Context switches, code instrumentation/emission, …
● Worse in testing environment: short run, little code reuse
■ Much better code reuse with Dr. Fuzz
pdfium_test with one page pdf file 100 times
Native Dr. Memory Dr. Fuzz Dr. Memory Dr. Fuzz

Light Mode Light Mode Full Mode Full Mode
37.04s 328.69s 75.75s 1553.74s 268.40s
8.9x 2.0x 41.9x 7.2x
13
● Function-level Fuzzing
● Focus On The Relevant Code
● Library API Fuzzing
● Runtime Options
■ -fuzz_module
■ -fuzz_function
■ -fuzz_offset
■ -fuzz_num_iters
■ -fuzz_call_convention
■ -fuzz_num_args
■ -fuzz_data_idx
■ -fuzz_size_idx
14
● Demo
15
● Fuzzing Test
● Dr. Fuzz Tool
16
Feedback Guided Fuzzing
● Execution Feedback
● Code/branch/path coverage
● System/function calls
● Trace
● Guidance
● Quantitatively measure the quality of input data
■ Bias to better input data mutation
■ Coverage guided fuzzing (-fuzz_coverage)
● Flipping each bit of initial input data
● Add current input as the mutator seed if discover new code
● Trace based analysis and symbolic execution
■ Smart input generation
17
Basic Block Coverage
A C D

coverage
block
foo() bar() cache
A
A A
C
B C
DynamoRIO D
D
18
Feedback Guided Fuzzing
● Demo
19
● Fuzzing Test
● Dr. Fuzz Tool
20
Customized Input Generation
● Initial Input Data

● Current value
● Specific value
● Corpus
● Mutation Algorithm
● Random/ordered
● Bit flip
● Dictionary
● Custom mutator
● Custom third-party mutator library
21
Customized Input Generation
● Demo
22
● Fuzzing Test
● Dr. Fuzz Tool
23
Dr. Fuzz vs LibFuzzer
● LibFuzzer
● A library for coverage-guided fuzz testing
● http://llvm.org/docs/LibFuzzer.html
● LibFuzzer
LibFuzzer + XSan Dr. Fuzz
Toolchain LLVM not required
Source code write dedicated code not required
Input corpus required not required
Advantages stack, globals libraries, asm, JIT
Performance = XSan (ASan: ~2x, MSan: ~3x) < DrM (Light: ~3x, Full: ~10x)
With coverage adds another ~2x negligible overhead
24
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
25
Dr. Fuzz Framework

Dr. Fuzz
block
foo() bar() cache
A
A
F
E
C
B C
DynamoRIO D
D
pre_func()
E E
F post_func()
F
26
Dr. Fuzz API
● Basic API
● drfuzz_fuzz_target(func_pc, ..., pre_func, post_func)
● drfuzz_get_arg()
● drfuzz_set_arg()
● pre_func()
● Set target function’s arguments
● Set other execution context if necessary
● post_func()
● Decide whether to repeat fuzzing or continue execution
● Provide feedback to the mutator
27
Dr. Fuzz API
● Demo
28
Dr. Fuzz API
● Load Mutator
● drfuzz_mutator_load
● drfuzz_mutator_unload
● Mutator Library API
● drfuzz_mutator_start
● drfuzz_mutator_has_next_value
● drfuzz_mutator_get_current_value
● drfuzz_mutator_get_next_value
● drfuzz_mutator_stop
● drfuzz_mutator_feedback
29
Dr. Fuzz API
● Demo
30
Dr. Fuzz API
● Misc API
● drfuzz_get_target_num_bbs
● drfuzz_get_target_user_data
● drfuzz_set_target_user_data
● ...
31
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Conclusion
32
Motivation: Memory Bugs
Memory bugs are challenging to detect and fix

• Memory corruption, reading uninitialized memory, memory leaks
Observable symptoms resulting from memory bugs are

often delayed and non-deterministic
• Errors are difficult to discover during regular testing
• Testing usually relies on randomly happening to hit visible symptoms
• The sources of these bugs are painful and time-consuming to track
down from observed crashes
Memory bugs often remain in shipped products and can

show up in customer usage
33
Meet the Doctor
Detects unaddressable memory

accesses
• Use-after-free
• Heap buffer/array overflow/underflow
• Wild access to invalid address
• Read beyond top of stack
Detects uninitialized memory reads

• Read before write, anywhere in memory
Detects memory leaks

• Unreachable heap objects
34
Dr. Memory
Detects invalid heap arguments

• Double free
• Allocate with new[], free with delete
Detects Windows handle leaks

• Kernel, user, GDI
Detects GDI usage errors

• Get/Release vs Create/Delete
• Thread ownership
• Delete while selected, etc.
35
Deployment
Operates purely at runtime

• No source code or object code modification required
Monitors third-party components and libraries

• More challenging to monitor with compiler or link based tools
Runs on Windows, Linux, and Android (native code)
Visual Studio integration

• External Tool output mode
36
Dr. Memory Demo
37
Implementation Strategy
Track the state of application memory using shadow

memory
• Track whether allocated and whether defined
Monitor every memory-related action by the application:

• Memory allocation at kernel layer (map file, anonymous map)
• Memory allocation at library layer (new, malloc, etc.)
• Memory read or write
• Stack adjustment
At exit or on request, scan memory to check for leaks
38
Shadow Metadata
Shadow each byte of memory + registers with 1 of 3 states:

allocate: mmap, calloc
allocate:
malloc, stack write
unaddressable uninitialized defined
deallocate
deallocate
39
Shadow Memory
Shadow Stack Heap Shadow Heap

Stack
defined header unaddr
uninit redzone unaddr
defined defined
malloc uninit
unaddr defined
redzone unaddr
padding unaddr
header unaddr
freed unaddr
40
The Uninitialized Whole Word Problem
Sub-word variables are moved around as whole words

• Sub-word often initialized as sub-word yet copied as whole word
• Reads involved in copying should not raise errors
Compare 16 bits
Copy 32 bits
byte 0 init init init
Initialize 16
byte 1 init init init

bits
byte 2 uninit uninit uninit

byte 3 uninit uninit uninit
Solution: report errors on “meaningful” reads only

• Use in compare, conditional branch, address register, or system call
Requires propagating metadata and shadowing registers

• Shadow metadata mirrors application data flow
41
Memory Leaks
Dr. Memory uses reachability-based leak detection

• A leak is memory that is no longer reachable by the application
• Memory that is never freed is not considered a leak
▪ Acceptable to not free memory whose lifetime matches process lifetime
At exit time, or on request, perform leak analysis

• Similar to mark-and-sweep garbage collection
Dr. Memory divides all allocated memory into categories

based on how it can be reached by live application pointers
• Any pointer-aligned and initialized pointer-sized word is considered a
potential pointer
42
Memory Leak Categories
Reachable = not a leak: malloc header
requested size
aligned, for application
initialized data
pointer
malloc padding
Not reachable, no way

malloc header
to free = a leak:
requested size
no pointer for application
found to any data
part of data!
malloc padding
43
Possibly Reachable Memory
malloc header
requested size
aligned, for application
initialized data
pointer
malloc padding
Memory that is reachable only via pointers to the middle of

the allocation, rather than the head
• These may or may not be legitimate pointers to that allocation
• A "possible leak"
44
Layered Heap Routines
application
C++: new
Heap 3
C library: malloc
Windows API:
HeapAlloc
Heap 1
Heap 2
Native API:
RtlAllocateHeap
45
Monitoring on Windows
System calls that allocate memory

• NtMapViewOfSection, NtUnmapViewOfSection, NtAllocateVirtualMemory,
NtFreeVirtualMemory, NtMapCMFModule, NtGdiCreateDIBSection
Kernel actions that adjust the stack

• Kernel-mediated control flow: callbacks, exceptions, and APCs, along
with corresponding system calls (NtContinue, NtCallbackReturn) and
interrupts (int 0x2b)
• Directly set thread stack pointer (NtSetContextThread)
46
Memory Reads and Writes by the Kernel
Must mark memory written by kernel as initialized

• Else will see many false positives
Must check that memory read by kernel is initialized

• Else can have false negatives
Must check that memory written by kernel is addressable

• Else can have false negatives
Thus, must know the size and shape of all in and out
parameters to all system calls
47
Dr. Syscall
Database of Windows system calls

• Originally based on Nebbett and Microsoft DDK/SDK headers
• Augmented with our own analysis
Two key operations:

• Top-level parameter iteration
• Deep memory blob iteration
48
Dr. Strace
System call tracer for Windows
Built on top of Dr. Syscall
Pretty-printing all of the types is a work-in-progress

• Contact us if you would like to contribute
49
Dr. Strace
NtOpenKeyEx
arg 0: 0x001fcd0c (type=HANDLE*, size=0x4)
arg 1: 0x109 (type=unsigned int, size=0x4)
arg 2: len=0x18, root=0x3c, name=150/152 "SOFTWARE\Microsoft\Windows NT\
CurrentVersion\LanguagePack\SurrogateFallback", att=0x40,
sd=0x00000000, sqos=0x00000000 (type=OBJECT_ATTRIBUTES*, size=0x4)
arg 3: REG_OPTION_RESERVED or REG_OPTION_NON_VOLATILE
(type=named constant, value=0x0, size=0x4)
succeeded =>
arg 0: 0x001fcd0c => 0x134 (type=HANDLE*, size=0x4)
retval: 0x0 (type=NTSTATUS, size=0x4)
NtQueryKey.KeyCachedInformation
arg 0: 0x134 (type=HANDLE, size=0x4)
arg 1: 0x4 (type=named constant, size=0x4)
arg 2: 0x001fcb5c (type=*, size=0x4)
arg 3: 0xb0 (type=unsigned int, size=0x4)
arg 4: 0x001fca34 (type=unsigned int*, size=0x4)
succeeded =>
arg 2: _KEY_CACHED_INFORMATION {_LARGE_INTEGER {0x1ca043f05a7a595},
int=0x0, int=0x4, int=0x1a, int=0x1, int=0xc, int=0x18, int=0x22}
(type=*, size=0x4)
arg 4: 0x001fca34 => 0x28 (type=unsigned int*, size=0x4)
retval: 0x0 (type=NTSTATUS, size=0x4)
50
Performance Comparison
51
Light Mode
Focus on unaddressable accesses: heap underflow and overflow
Insert redzone around application malloc chunks with special value

(pattern) like 0xf1fd in the redzone
malloc pre- requested size for post- malloc

● Instrumentation
header redzone application data redzone padding
○ Check value before every memory access

○ If match, check whether address is in redzone
● ~3x overhead (vs ~10x full mode)
● Only mode available for 64-bit and Android
52
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Conclusion
53
Goals
Profile, monitor, or inspect application binaries as they run

• Build customized dynamic program inspectors
Support comprehensive inspection tools

• Not just sampling-based tools
Target applications that include legacy components, third-

party libraries, or dynamically-generated code
• Want to inspect whole program even if cannot recompile it all
54
Reach of Toolchain Control Points
runtime inspector
“DynamoRIO”?!?
Dynamo Dynamo
@HP Labs @HP Labs
on PA-RISC on x86
late 1990’s 2000
RIO @MIT
Dynamo + RIO →
(Runtime Introspection
DynamoRIO
and Optimization)
1999 2001
56
DynamoRIO History
VMware Google
DynamoRIO Determina
acquires sponsors
@MIT security startup
Determina Dr. Memory
2001 2003 2007 2010
open-sourced
binary releases
BSD license
2002 2009
57
DynamoRIO Tool Platform Design Goals
Efficient
• Near-native performance
Transparent
• Match native behavior
Comprehensive
• Control every instruction, in any application
Customizable
• Adapt to satisfy disparate tool needs
58
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Efficient
● Transparent
● Comprehensive
● Customizable
● Conclusion
59
Basic Interpreter
application code
foo() bar()
A
interpreter
B C
fetch decode execute
Slowdown: 300x
60
Improvement #1: Basic Block Cache

block
foo() bar() cache
A A
B C C
DynamoRIO
D D
E E
F F
Slowdown: 300x 25x

61
Improvement #2: Linking Direct Branches

block
foo() bar() cache
A A
B C C
DynamoRIO
D D
E E
F F
Slowdown: 300x 25x 3x

62
Improvement #3: Linking Indirect Branches

block
foo() bar() cache
A A
B C C
DynamoRIO
D D
E E
indirect
branch
F F lookup
Slowdown: 300x 25x 3x 1.2x

63
Improvement #4: Trace Building
application code basic trace

block cache
foo() bar() cache
A A
B C C ind. br.
DynamoRIO stays
on
A
D D trace? C
D
E E E
indirect
?
branch
F F F
lookup
Slowdown: 300x 25x 3x 1.2x 1.1x

64
Base Performance: SPEC 2006
65
Avoiding Intermediate Layers
36.3
7.2 6.1
5.0
1.3 1.0
66
No Intermediate Layer
IR mirrors underlying ISA

• Preserves optimized application code
• Intermediate layers incur significant performance impact
▪ QEMU (user-mode) 6x slower than DR, Valgrind 4x slower than DR
• This is the key to good performance
Still have an abstraction layer

• Block or trace = list of instructions
• Instruction = lists of source and destination operands
• Tool code often still cross-platform
▪ “Does this instruction read memory?”
67
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Efficient
● Transparent
● Comprehensive
● Customizable
● Conclusion
68
Unavoidably Intrusive
processprocess
app cache
A A
process B C C process
DynamoRIO
D D
thread
thread
thread
thread
thread
thread
E E
look
up
F F
operating system
69
Arbitrary Interleaving

block cache
malloc() cache
A call malloc() A
B C DynamoRIO C
E
indirect
branch
F thread-safe lookup
re-entrant!
70
Separate Resources
application
Win32 API
application Win32 DLLs
system call gateway system call gateway
operating system operating system
Linux Windows
71
Private Libraries
application client
Win32 API
Win32 DLLs Private DLLs DynamoRIO
system call gateway
operating system
72
Dynamically Modified Code

block cache
foo() bar() cache
A A
B C C
DynamoRIO
A
D
X D C
D
E E E
indirect
?
branch
F F F
lookup
73
Code Cache Consistency
ARM x86
I-Cache D-Cache I-Cache D-Cache
A: A: A: A:
B: B: B: B:
C: C: C: C:
D: D: D: D:
store B store B
flush B jump B
jump B
74
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Efficient
● Transparent
● Comprehensive
● Customizable
● Conclusion
75
Above the Operating System
processprocess
app cache
A A
process B C C process
DynamoRIO
D D
thread
thread
thread
thread
thread
thread
E E
look
up
F F
operating system
76
Intercepting Windows Messages
user mode kernel mode
message pending
modify save user context
shared library
memory image
dispatcher
majority of
executed
time
code in a dispatcher
typical message handler
Windows
application
no message pending
restore context
77
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Efficient
● Transparent
● Comprehensive
● Customizable
● Conclusion
78
DynamoRIO + Client Custom Inspector

client code block cache
foo() bar() cache
A
A
B C C
DynamoRIO A
D D C
D
E E E
indirect
?
branch
F F F
lookup
79
Primary Client Events: Code Stream
Client has opportunity to inspect and potentially modify

every single application instruction, immediately before it
executes
Entire application code stream

• Basic block creation event: can modify the block
• For comprehensive instrumentation tools
Or, focus on hot code only

• Trace creation event: can modify the trace
• Custom trace creation: can determine trace end condition
• For optimization and profiling tools
80
Transformation Time vs Execution Time
average
instruction
length
transformation
application code time basic trace
client code block cache
foo() bar() cache
call
instruction
A execution
A count
execution time
B C C
DynamoRIO
A
D C
D
D
E
E E
indirect
?
F
branch
F F
lookup
81
Secondary Client Events
Application thread creation and deletion
Application library load and unload
Application exception/signal
• Client chooses whether to deliver, suppress, bypass the app handler,
or redirect control
Application pre- and post- system call

• Client can inspect/modify call number, params, or return value
Bookkeeping: init, exit, cache management, etc.
82
DynamoRIO API: General Utilities
Safe utilities for maintaining transparency

• Separate stack, memory allocation, file I/O
• Thread-local storage, synchronization
• Create client-only thread or private itimer
Application control
• Suspend and resume all other threads
Application inspection
• Address space querying
• Module iterator
• Processor feature identification
83
DynamoRIO API: Code Manipulation
Clean calls to C or C++ code

• Automatically inlined for simple callees
Full IA-32/AMD64 instruction representation

• Includes implicit operands, decoding, encoding
State preservation
• Eflags, arith flags, floating-point state, MMX/SSE state
• Spill slots, TLS, CLS
Dynamic instrumentation
• Replace code in the code cache
84
DynamoRIO API: Extension Libraries
Extension libraries shipping with DynamoRIO

• drmgr: multi-instrumentation mediation
• drsyms: symbol table and debug info lookup
• drwrap: function wrapping and replacing
• drutil: memory address calculation, string loop expansion
• drx: multi-process management, misc utilities
• drsyscall: system call names, numbers, parameter types
• drreg: scratch register management
• umbra: shadow memory
• drcallstack: callstack walking (not yet librarified)
• drmalloc: heap allocation interception (not yet librarified)
85
DynamoRIO Client with Extensions
client code
drx drutil
basic trace
application code client code
drmgr block cache
cache
foo() bar()
A
A
A C
C D
B C
DynamoRIO D
D
86
drdecodelib
Internal decoder exported as an isolated library
Decoder, encoder, disassembler, and general instruction

manipulation
Supports x86, AMD64, and AArch32 A32 + T32
Instruction representation includes all operands (including

implicit operands) and condition code effects
87
Powerpoint Under Inspector
88
DynamoRIO versus Pin
Pin = insert callout/trampoline only

• Pin tries to inline and optimize
• Client has little control or guarantee over final performance
• Proprietary
DynamoRIO = arbitrary code stream modifications

• Callout/trampoline with inlining, plus…
• Client has full control over all inserted instrumentation
▪ Result can be significant performance difference:
PiPA memory profiler + cache simulator 25% faster with DR
• Supports ARM and (coming soon) AArch64

• Open-source
89
Outline
● Introduction
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● Implementation
■ Efficient
■ Transparent
■ Comprehensive
■ Customizable
● Security applications
■ Program shepherding
● Conclusion
90
Anatomy of a Memory-Based Attack
network
ENTER
CORRUPT DATA system and

application
memory
HIJACK PROGRAM COUNTER
COMPROMISE
kernel
91
Critical Data: Control Flow Indirection
• Subroutine calls
– Return address and activation records on visible stack
• Dynamic library linking
– Function exports and imports
• Object oriented polymorphism: dynamic dispatch
– Vtables
• Callbacks – registered function pointers
– Event dispatch, atexit
• Exception handling
Any problem in computer science can be solved with another layer

of indirection.
- David Wheeler
92
Critical Data: Control Flow Exploits
• Return address overwrite

– Classic buffer overflow
• GOT overwrite
• Object pointer overwrite or uninitialized use
• Function pointer overwrite
– Heap, stack, data, PEB
• Exception handler overwrites
– SEH exploits
Any problem in computer science can be solved with another layer

of indirection. But that usually will create another problem.
- David Wheeler
93
Preventing Data Corruption Is Difficult
• Stored program addresses legitimately manipulated by

many different entities
– Dynamic linker, language runtime
• Intermingled with regular data
– Return addresses on stack
– Vtables in heap
• Even if could distinguish a good write from a bad write,
too expensive to monitor all data writes
94
Insight: Hijack Violates Execution Model
Hardware
Interface
Typical
Application Security Attack
Execution Model
95
Goal: Shrink Hardware Interface
Constrained
Hardware Interface
Typical
Application Security Attack
Execution Model
96
Program Shepherding
• Monitor all control-flow transfers during program

execution
– DynamoRIO is in perfect position to do this
• Validate that each transfer satisfies security policy based
on execution model
– Application Binary Interface (ABI): calling convention, library
invocation
• The application may be damaged by data corruption, but
the system will not be compromised by hijacking control
flow
97
Technique 1: Restricted Code Origins

transformation block cache
time cache
A
unmodified
code
C
D
program D
modified shepherding
code
indirect
E
branch
lookup
98
Technique 2: Restricted Control Transfers

transformation block cache
foo() bar() time cache
A A
B C C
A
program
D D C
shepherding
D
E E call E
return ?
F F F
jump
99
Technique 3: Un-circumventable Sandboxing
application code basic block cache
foo() bar()
A
B
A pre-check
B system call
jump system call post-check
C C
pre-check
system call
jump post-check
C
10
Security Policies: Restricted Code Origins
Self-contained
dynamically generated
code with no system LoadLibrary(),
calls dlopen()
Code in executable Only code from disk,

memory regions originally loaded
Any code
code origins
less restrictive more

restrictive
JIT Plug-in
10
Restricted Code Origins In Practice
• Tradeoffs between compatibility and security

• Allowed modified code:
– Libraries: relocation, rebinding
– Hooks: let them write once
• Allowed generated code:
– Stylized code fragments:
• Closures on stack/heap used by Visual Basic and gcc nested
functions
– JITs:
• Difficult if mix code and data and do not mark code regions
• Fallback: native execution, rely on language VM for security
– Injected threads, APC’s
• All other non-unmodified-image code disallowed
102
Security Policy: Function Returns
Only to after calls StackGuard canary Only to caller
Direct call
targeted by only StackGhost
Unrestricted one return transparent xor
function returns

restrictive
nearly all (and more
programs expensive!)
103
Security Policy: Inter-Module Calls + Jumps
Only to import of
Unrestricted source module
Only to bindings
Only to export of given in an
target module interface list
call/jump between modules

restrictive
104
Security Policy: Intra-module Calls + Jumps
If have symbol table:

only within same
function or to function Only to bindings
entry points given in an
If no symbol table:
unrestricted interface list
call/jump within module

restrictive
program w/o program with
debug info debug info
105
DynamoRIO for Malware Analysis
Advantages versus VM-based instrumentation

• Semantic gap
▪ Inside guest user mode, can use clean interfaces and more easily gather
more and finer-grained information
• Performance
▪ QEMU software virtualization 6x+ slower than DR
• Ease of use
▪ Tool API
106
Conclusion
● Summary
● Dr. Fuzz Tool
● Dr. Memory
● DynamoRIO
● More information:
● http://dynamorio.org
● http://drmemory.org
● http://groups.google.com/group/dynamorio-users
● http://groups.google.com/group/drmemory-users
107
Optional Slides
Direct Code Modification
e9 37 6f 48 92 jmp <callout>
Kernel32!TerminateProcess:
7d4d1028 7c 05 jl 7d4d102f
7d4d102a 33 c0 xor %eax,%eax
7d4d102c 40 inc %eax
7d4d102d eb 08 jmp 7d4d1037
7d4d102f 50 push %eax
7d4d1030 e8 ed 7c 00 00 call 7d4d8d22
Debugger Trap Too Expensive
cc int3 (breakpoint)
Kernel32!TerminateProcess:
7d4d1028 7c 05 jl 7d4d102f
7d4d102a 33 c0 xor %eax,%eax
7d4d102c 40 inc %eax
7d4d102d eb 08 jmp 7d4d1037
7d4d102f 50 push %eax
7d4d1030 e8 ed 7c 00 00 call 7d4d8d22
Base Performance
SPEC CPU2000 Server Desktop

Transparency Landscape
Principle 1: Principle 2: Principle 3:

As few changes Hide necessary Separate
as possible changes resources
application code, machine context,

Code
stored addresses cache consistency
stack, heap,
separate stack,
Data registers,
heap, context, i/o
condition flags
threads,
Concurrency disjoint locks
memory ordering
Other preserve errors

Base Performance Comparison (No Tool)
BBCount Performance Comparison
Memory-Based Security Exploits
Microsoft Security Bulletins 2003-2005
11
Results for Restricted Code Origins
Technique 1
Technique 2 Technique 3
Attack Type Restricted Code
Origins
Injected code STOPPED
Existing code
• Injected code attack: introduce code masquerading as

data
• Code reuse attack: execute existing code in novel order
– “Return-to-libc”
• Often combined
– For reliable buffer address – find “jmp stack pointer”
– For bypassing NX
Results for Restricted Control Transfers
Restricted
Restricted Code
Attack Type Origins
Control Technique 3
Transfers
Chained calls STOPPED
Return HINDERED
Existing code
Other transfer
Not imported STOPPED

Inter-module
Call or jump
Imported
Have Mid-func STOPPED

entry
Intra-module info Func entry
No info
117
Results for Un-circumventable Sandboxing
Restricted Code Restricted Control Un-circumventable

Attack Type Origins Transfers Sandboxing
Chained calls STOPPED
Return HINDERED HINDERED

Existing code
Other transfer
Not imported STOPPED

Inter-module
Call or jump
Imported HINDERED
Have entry Mid-func STOPPED
Intra-module info
Func entry HINDERED
No info HINDERED
118
Determina, Inc.
• Startup company in host intrusion prevention market

• “Memory Firewall” product = program shepherding
• “Liveshield” product = patching without rebooting using
the code cache
• Two successful rounds of funding, 40+ employees, and
~50 customers including large financials
• Acquired by VMware in 2007
Minimal False Positives
• Carefully crafted security policies

• Automated exemption generation: ‘staging mode’
• Determina: 50 customers, 10,000 machines
– No false positives in MSFT apps
– <50 unique false positives in 3rd party libraries
• We treated these false positives as bugs rather than
customer driven policies
– Radically different from other security products
Kiriansky, Bruening, Amarasinghe.

“Secure Execution via Program Shepherding” SEC’02
Self-Protection
ASLR of code cache, heap, and stacks
Guard pages around every cache, heap, and stack block

• Stops sequential loops from hitting any DR memory
Zero state on DR stack while in the cache
Write-protected memory
• Data sections in DR library
• DR’s own generated code (indirect branch lookup, etc.)
• Code cache and heap is option-controlled: perf tradeoff
Hiding from library enumeration and memory queries

DrFuzz SecDev 2016

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DrFuzz SecDev 2016

Uploaded by

Copyright:

Available Formats

Using Dr. Fuzz, Dr.

Derek Bruening bruening@google.com

● Dr. Fuzz Tool

● Dr. Fuzz Framework

application code basic

transformation time execution time:

application code basic

● Dr. Fuzz Tool

● Dr. Fuzz Framework

● Memory Checking Tools

application code basic

pdfium_test with one page pdf file 100 times

Native Dr. Memory Dr. Fuzz Dr. Memory Dr. Fuzz

37.04s 328.69s 75.75s 1553.74s 268.40s

8.9x 2.0x 41.9x 7.2x

application code basic

● Initial Input Data

LibFuzzer + XSan Dr. Fuzz

Toolchain LLVM not required

Source code write dedicated code not required

Input corpus required not required

Advantages stack, globals libraries, asm, JIT

With coverage adds another ~2x negligible overhead

● Dr. Fuzz Tool

● Dr. Fuzz Framework

application code basic

● Dr. Fuzz Tool

● Dr. Fuzz Framework

Memory bugs are challenging to detect and fix

Observable symptoms resulting from memory bugs are

Memory bugs often remain in shipped products and can

Detects unaddressable memory

Detects uninitialized memory reads

Detects memory leaks

Detects invalid heap arguments

Detects Windows handle leaks

Detects GDI usage errors

Operates purely at runtime

Monitors third-party components and libraries

Runs on Windows, Linux, and Android (native code)

Visual Studio integration

Track the state of application memory using shadow

Monitor every memory-related action by the application:

At exit or on request, scan memory to check for leaks

Shadow each byte of memory + registers with 1 of 3 states:

unaddressable uninitialized defined

Shadow Stack Heap Shadow Heap

Sub-word variables are moved around as whole words

byte 1 init init init

byte 2 uninit uninit uninit

Solution: report errors on “meaningful” reads only

Requires propagating metadata and shadowing registers

Dr. Memory uses reachability-based leak detection

At exit time, or on request, perform leak analysis

Dr. Memory divides all allocated memory into categories

Reachable = not a leak: malloc header

Not reachable, no way

Memory that is reachable only via pointers to the middle of

System calls that allocate memory

Kernel actions that adjust the stack

Must mark memory written by kernel as initialized

Must check that memory read by kernel is initialized

Must check that memory written by kernel is addressable