July 24, 2008 | NICECAP Site Visit
Software Exploit Prevention and Remediation via Software Memory
ProtectionPIs: Clark Coleman, Jack Davidson, David Evans,
John Knight, and Anh Nguyen-Tuong
Department of Computer Science, University of Virginia
July 24, 2008 | NICECAP Site Visit2
Software Exploit Prevention and Remediation via Software Memory Protection
Presentation Outline
Introduction and Staffing: Jack DavidsonResearch Overview: Clark Coleman, Jason HiserBreakDemonstration: Michele CoEvaluation and Metrics: Michele CoProject Schedule, Milestones, Finances, and Technology Transfer: Jack Davidson
July 24, 2008 | NICECAP Site Visit3
Software Exploit Prevention and Remediation via Software Memory Protection
Project Staffing
Investigators– Clark Coleman (Research Scientist)– Jack Davidson, Dave Evans, John Knight (Faculty)– Anh Nguyen-Tuong (Senior Scientist)
Staff– Ann Bailey (Research Assistant)– Mark Bailey (Visiting Associate Professor)– Michele Co (Research Associate)– Jason Hiser (Research Scientist)– Sudeep Ghosh, Joy Kamunyori and Hong Pham (Graduate
Students)– Nicholas Williams and Kevin Binswanger (Undergraduates)
July 24, 2008 | NICECAP Site Visit4
Software Exploit Prevention and Remediation via Software Memory Protection
Threat Model
A program contains memory access vulnerabilities (not all memory operations are guaranteed to stay within proper bounds)An attacker can provide malicious input causing a memory overwriting error which compromises the program
July 24, 2008 | NICECAP Site Visit5
Software Exploit Prevention and Remediation via Software Memory Protection
The Research Problem
Protect a running program from memory overwriting exploits, with these requirements:
– Only a program executable is available (no source code)– Provide a general defense, not targeting a subclass of
memory overwriting attacks– Provide recovery and repair of vulnerable programs– Low enough overhead to be usable in real computing
environments
Prior work relaxed one or more of these requirements
July 24, 2008 | NICECAP Site Visit6
Software Exploit Prevention and Remediation via Software Memory Protection
Software Memory Protection (SMP)
A general memory overwriting defense, including remediationFour components operate directly on program binaries:
– A Profiler can optionally be run once, before other SMP tools, to provide information to those tools
– A Static Analyzer analyzes memory operations and vulnerabilities off line
– mmStrata (Memory Monitor Strata), a virtual execution environment that watches vulnerable operations at run time and prevents an attacker from compromising the program
– Stratafier incorporates mmStrata into the executable to be protected
July 24, 2008 | NICECAP Site Visit7
Software Exploit Prevention and Remediation via Software Memory Protection
Development Schedule
Work divided into six prototypes– Prototype 1: Protect global (static) data pointer operations at coarse
granularity (completed; demonstrated in Boston)– Prototype 2: Protect heap and stack pointer operations at coarse
granularity (completed; demonstrated January 31)– Prototype 3: Protect global and stack pointer operations at finer
granularity (March 28, 2008)– Prototype 4: Protect heap pointer operations at finer granularity (May
2, 2008)– Prototype 5: Adaptive feedback scheme (July 4, 2008)– Prototype 6: Remediation (recovery and repair) ongoing (due
September 5, 2008; partial demo today)
July 24, 2008 | NICECAP Site Visit8
Software Exploit Prevention and Remediation via Software Memory Protection
Final SMP Operation (simplified)
Program binary
Offline Processing
Program binaryapache
executable
mmStrata binary
(runtime)
apache executable (protected)
RuntimeOffline
Adaptive feedback
July 24, 2008 | NICECAP Site Visit9
Software Exploit Prevention and Remediation via Software Memory Protection
Prototype 5 Operation
Program binary
Stratafier (offline)
Program binary
Entry point
apache executable
Entry point
mmStrata binary
(runtime)
apache executable (protected)
Static Analyzer (offline)
Annotations file
(read at runtime)
RuntimeOffline
mmStrata library
Profiler (offline)
optional
Adaptive feedback
July 24, 2008 | NICECAP Site Visit11
Software Exploit Prevention and Remediation via Software Memory Protection
Prototype 5 Operation
Program binary
Stratafier (offline)
Program binary
Entry point
apache executable
Entry point
mmStrata binary
(runtime)
apache executable (protected)
Static Analyzer (offline)
Annotations file
(read at runtime)
RuntimeOffline
mmStrata library
Profiler (offline)
optional
Adaptive feedback
July 24, 2008 | NICECAP Site Visit12
Software Exploit Prevention and Remediation via Software Memory Protection
What is SDT?
The programmatic modification of a running program’s binary instructions
Software layer mediates program execution by modifying (translating) instructions before they execute on host CPU
Application Binary
Dynamic Translator
Operating System
CPU
July 24, 2008 | NICECAP Site Visit13
Software Exploit Prevention and Remediation via Software Memory Protection
Strata Virtual Machine
ContextCapture
ContextSwitch Next PC
TranslateDecodeFetch
NewFragment
Finished?
Dynamic Translator
NewPC Cached?
Application Binary
System Start (first PC)
Fragment Cache
Direct Conditional branchTrampoline Non-control instructions
July 24, 2008 | NICECAP Site Visit14
Software Exploit Prevention and Remediation via Software Memory Protection
ContextCapture
ContextSwitch Next PC
TranslateDecodeFetch
NewFragment
Finished?
Dynamic Translator
NewPC Cached?
Application BinaryFragment Cache
Instrumenting Applications with Strata
Application inst.Instrumentation inst.
Instrumentation LibraryDouble_free_check()
store_check()Taint_track()
call store_check
mov [$esp+4], eax
load_check()
sh_eax=sh_ebx
mov eax, ebx
July 24, 2008 | NICECAP Site Visit15
Software Exploit Prevention and Remediation via Software Memory Protection
Keep metadata for each storage location– Numeric (n)– Pointer to referent (p)– Offset from pointer to pointer for strcpy/memcpy (o)
Update metadata for each program operation– (n)+(n) (n)– (p)+(n) (p) – (p1)-(p2) (o(1,2)) – (p1)+(o(1,2)) (p2)– Other operations (*,/,<<,>>,^,&,|) (n)
Verify pointer dereferences– Pointers may wander out of, then back to referent object without error.– Fine-grain detection on per-pc basis.
eax
Stack
ebxecxedx
Heap
Static DataCode
sh_eax (p)
(p)sh_stk (n)
(n)
sh_ebx (n)sh_ecx (n)sh_edx (n)
nnpn
nn
pnpnn
SMP Instrumentation
July 24, 2008 | NICECAP Site Visit16
Software Exploit Prevention and Remediation via Software Memory Protection
Example
int a[10];
int user_is_root=0;
main() {
int *p=a, i, k;
… // read i from user
p+=i;
… // read k from user
*p=k; // is this a vuln?…
}
mov eax, $0x8004000
…
add eax, ebx
…
mov [eax], ecx
…
Unfortunately, no source available. What do we do with the binary code?
July 24, 2008 | NICECAP Site Visit17
Software Exploit Prevention and Remediation via Software Memory Protection
mov [sh_eax], $(p:0x8004000-0x8004040)mov eax, $0x8004000 ; p=a;
…call sh_add(sh_eax=sh_eax ╬ sh_ebx)add eax, ebx ; p+=i;…call is_OK?(sh_eax,eax)call store_update(eax,ecx)mov [eax], ecx ; *p=k
…
Example Cont.
Step 1: Dynamically instrument code
mov eax, $0x8004000
…
add eax, ebx
…
mov [eax], ecx
…
Step 2: Execute instrumented code
July 24, 2008 | NICECAP Site Visit18
Software Exploit Prevention and Remediation via Software Memory Protection
Keys to EfficiencyInsert instrumentation inline when possibleMinimal instrumentation; custom design code for common instructions
– add/sub reg, $imm -- no overhead– mov reg, $imm -- 1 instruction overhead– mov reg, reg -- 2 instructions overhead– memory read – splay tree operation– memory write – splay tree operation + bounds check
Static analysis– Eliminate splay operations and bounds checking– Live register analysis to minimize instrumentation overhead– Eliminate type system operations where unnecessary
Profile driven optimizations (can be done online)– Detect loads where type is always (n)– Detect indirect branch targets for better static analysis
July 24, 2008 | NICECAP Site Visit20
Software Exploit Prevention and Remediation via Software Memory Protection
Prototype 5 Operation
Program binary
Stratafier (offline)
Program binary
Entry point
apache executable
Entry point
mmStrata binary
(runtime)
apache executable (protected)
Static Analyzer (offline)
Annotations file
(read at runtime)
RuntimeOffline
mmStrata library
Profiler (offline)
optional
Adaptive feedback
July 24, 2008 | NICECAP Site Visit21
Software Exploit Prevention and Remediation via Software Memory Protection
mmStrata Profiler
Static Analyzer shortcomings– Many problems undecidable at static analysis time– Common case information is available at profile time– Annotations merged with static analyzer information
Augment Static Analysis–Reduce false positives–Provide speculative optimizations
Implementation overview– Built on Strata virtual machine technology– Uses mmStrata code base for memory access analysis
July 24, 2008 | NICECAP Site Visit22
Software Exploit Prevention and Remediation via Software Memory Protection
Profiler Annotations
All annotations are of two general categories– Informative – Optimizing
Goals of current profiler annotations1. Reduce false positives in mmStrata2. Inform the static analyzer of fine-grained memory accesses3. Identify indirect branch targets4. Identify load instructions with invariant type
Four major advances to state of the art
July 24, 2008 | NICECAP Site Visit23
Software Exploit Prevention and Remediation via Software Memory Protection
1. Reducing False Positives
Prototype 2 source of false positives was “pre-decremented constants”
– Difficult (sometimes impossible) to detect statically– Relatively straightforward in mmStrata Profiler
int a[100]; // 0x8000int b[100]; // 0x8190foo(int i, int j) {do {
b[i-1]=j;i++;
} while (i<=100);}
mov ecx, [ebp+4]lea eax, $0x818c // &b - 4
L1: mov [eax+ebx], ecxadd ebx, $1cmp ebx, $100jle L1
July 24, 2008 | NICECAP Site Visit24
Software Exploit Prevention and Remediation via Software Memory Protection
1. Reducing False Positives cont’d
The profiler can detect that 0x818c always accesses bAnnotations tell mmStrata 0x818c points to b
mov ecx, [ebp+4]lea eax, $0x818c // &b - 4
L1: mov [eax+ebx], ecxadd ebx, $1cmp ebx, $100jle L1
July 24, 2008 | NICECAP Site Visit25
Software Exploit Prevention and Remediation via Software Memory Protection
2. Analyzing Memory GranularityPrototypes 1-2 were coarse grained
– local stack frame– global static data object– heap-allocated object
Coarse-grained objects can have finer structuresstruct foo {
int *CriticalPtr;char buffer[128];int (*FuncPtr)();
};
Prototypes 3-4 extend earlier prototypes to provide finer-grained protection
– Static analysis alone prone to producing false positives– Runtime memory access patterns are more reliable
July 24, 2008 | NICECAP Site Visit26
Software Exploit Prevention and Remediation via Software Memory Protection
2. Analyzing Memory Granularity: Issues
Few exploits are fine grained– Coarse-grained SMP already increases the difficulty of an exploit by an order of magnitude or more
State-of-the-art static analysis over-refines granularity User will not tolerate false positives
Solution: Have the static analyzer conservatively refine the granularity of data objects, using input from a profiling run
July 24, 2008 | NICECAP Site Visit27
Software Exploit Prevention and Remediation via Software Memory Protection
2. Analyzing Memory Granularity: ProfilingProfiler examines each memory accessEach memory access is classified
– Direct: mov eax,globalname or mov ebx,[esp+4]
– Indirect: mov [ebx],eax or mov eax,[ebx+ecx]
– Scaled: mov eax,[ebx+ecx*4] (if ebx -> referent start addr)
Profiler records objects and access typesAnnotations summarize accesses, on an instruction/data-object pair basisCurrent Limitations
– Large objects (over 32k for memory purposes)– Variable sized objects allocation points
• alloca and some malloc sites
::
<unaccessed><unaccessed>
<scaled><scaled><scaled><scaled><scaled><scaled><scaled><scaled>
<unaccessed><unaccessed><unaccessed><unaccessed><unaccessed><unaccessed><unaccessed><unaccessed>
foo@0x8200
July 24, 2008 | NICECAP Site Visit28
Software Exploit Prevention and Remediation via Software Memory Protection
3. Identifying Indirect Branch Targets
Profiler watches and records all IB targets– Code discovery– Interprocedural static analysis
• “Safe” function optimizations
mmStrata monitors for new IB targets– Avoid unsafe optimizations if profiler information is
incomplete
July 24, 2008 | NICECAP Site Visit29
Software Exploit Prevention and Remediation via Software Memory Protection
4. Invariant Type Optimizations
Memory operation instrumentation is very expensive– mmStrata instrumentation needs to access large data structures
mmStrata must know if loaded value is pointer. – mov eax, [esp + 4]
Almost all mmStrata work avoidable if eax‘s type is known to be numericProfiler detects memory loads with numeric shadow types
– Can also be performed online• Initial slowdown• Same security guarantees
July 24, 2008 | NICECAP Site Visit30
Software Exploit Prevention and Remediation via Software Memory Protection
mmStrata and Profiler Summary
mmStrata dynamically instruments programs to avoid memory overwriting attacksExtensions to type system to avoid classes of false positives4 types of profiler-derived annotations
– Reduce false positives– Improve performance
Significant advancement to state of the art in terms of false positives and performance (results later)
July 24, 2008 | NICECAP Site Visit32
Software Exploit Prevention and Remediation via Software Memory Protection
Prototype 5 Operation
Program binary
Stratafier (offline)
Program binary
Entry point
apache executable
Entry point
mmStrata binary
(runtime)
apache executable (protected)
Static Analyzer (offline)
Annotations file
(read at runtime)
RuntimeOffline
mmStrata library
Profiler (offline)
optional
Adaptive feedback
July 24, 2008 | NICECAP Site Visit33
Software Exploit Prevention and Remediation via Software Memory Protection
Static Analyzer
Tasks– Disassemble executable into higher level format– Determine locations of code and data– Identify pointer writes and pointer arithmetic that would
cause false positives in mmStrata– Optimization: Identify instructions that mmStrata can
ignore– Identify boundaries between data items, including fields
within structures, local variables within the stack frame
Implemented as a plugin for IDA Pro
July 24, 2008 | NICECAP Site Visit34
Software Exploit Prevention and Remediation via Software Memory Protection
Static Analyzer Progress by Prototype
Prototypes 1-2 (completed)– Emit annotations describing each function (address and
size)– Emit annotations describing global static data (address
and size; coarse grained)– Analyze stack frame regions (local variables, return
address, saved registers, etc.)– Analyze all instructions using pointers into the stack– Solve the code/data identification problem
July 24, 2008 | NICECAP Site Visit35
Software Exploit Prevention and Remediation via Software Memory Protection
Static Analyzer Recent Work
Prototypes 3-4: Infer Data Granularity– Process profiler memory access annotations– Infer the fine grained structure of data
Optimization– Intraprocedural data flow analysis framework – Type inference system– Metadata liveness analysis– Redundant metadata detection
Informative annotations used in recovery
July 24, 2008 | NICECAP Site Visit36
Software Exploit Prevention and Remediation via Software Memory Protection
Granularity Example: Stack
Stack buffer overflow could overwrite local pointer (fine-grained attack) or overwrite return address (coarse-grained attack)Most reported attacks have been coarse grained
Incoming arguments
Return address
Saved frame pointer
Caller-saved registers
Callee-saved registers
Local stack frame
Local var.Local ptr.
Local buffer
Outgoing arguments
July 24, 2008 | NICECAP Site Visit37
Software Exploit Prevention and Remediation via Software Memory Protection
Granularity: Processing Profiler Annotations
The profiler produces annotations for each instruction/data-object-accessed pairA few instructions access objects of varying sizes (e.g. memset() is often used to initialize objects)
– Annotations for these instructions are discarded by the static analyzer
Remaining instruction/object pairs imply common data types
July 24, 2008 | NICECAP Site Visit38
Software Exploit Prevention and Remediation via Software Memory Protection
Granularity: Inferring Data Types
Transitive closure of instruction/object pairs form a data type webGranularity inference merges all access pattern annotations for all data objects in a type
July 24, 2008 | NICECAP Site Visit39
Software Exploit Prevention and Remediation via Software Memory Protection
Granularity: Merging Memory Access Patterns
All profiler annotations for objects of one data type are merged
DirectInstruction 2
DirectDirectDirect
struct foo {int *CriticalPtr;char buffer[128];int (*FuncPtr)();
}; IndirectIndirect
IndirectIndirect
Instruction 3
IndirectIndirect
DirectDirectDirectDirect
DirectDirectDirectDirect
Merged
DirectDirectDirectDirect
IndirectIndirectIndirectIndirectIndirectIndirectIndirectDirectDirectDirectDirect
Merged
July 24, 2008 | NICECAP Site Visit40
Software Exploit Prevention and Remediation via Software Memory Protection
Granularity Annotations
Instructions 1 and 2 get no annotation; Instruction 3 can access all indirect bytes
July 24, 2008 | NICECAP Site Visit41
Software Exploit Prevention and Remediation via Software Memory Protection
Optimizing Annotations
Foundation: Intraprocedural data flow analysis based on SSA formmov eax,[esp+12] ; eax1 := [esp+12]shl eax,2 ; eax2 := eax1 << 2
mov [ebx+eax],esi ; [ebx1+eax2] := esi1
Type inference performed across def-use chains
July 24, 2008 | NICECAP Site Visit42
Software Exploit Prevention and Remediation via Software Memory Protection
Type Inference
Some operations imply a pointer dereference, others imply a non-pointer (“numeric”) usagemov eax,[esp+12] ; eax1 := [esp+12]shl eax,2 ; eax2 := eax1 << 2
mov [ebx+eax],esi ; [ebx1+eax2] := esi1
Register eax1 is only used as a numericIf register ebx1 is analyzed to be a pointer, then eax2 must be a numeric index register
July 24, 2008 | NICECAP Site Visit43
Software Exploit Prevention and Remediation via Software Memory Protection
Type Inference: Optimizing Annotations
If the usage is always numeric, mmStratadoes not need to look up the metadata in memorymov eax,[esp+12] ; eax1 := [esp+12]
An optimizing annotation tells mmStrata not to look up the metadata for [esp+12]; just set the metadata for eax to numericTrue even if [esp+12] held a pointer!
July 24, 2008 | NICECAP Site Visit44
Software Exploit Prevention and Remediation via Software Memory Protection
Type Inference: Optimizing Annotations cont’d
Some operations have their result type determined by input operand typesadd eax,ebx ; eax2 := eax1+ebx1
If ebx is analyzed to be numeric, eax2 will retain the type of eax1
– If eax was a pointer, it is still a pointer; if numeric, it is still a numeric
– Annotation: no work at all for mmStrata to do
July 24, 2008 | NICECAP Site Visit45
Software Exploit Prevention and Remediation via Software Memory Protection
Detecting Dead Metadata
Some instructions cause mmStrata to fetch metadata that will never be usedmov eax,[esp+12] ; eax1 := [esp+12]mov eax,[ebx+eax] ; eax2 := [ebx1+eax1]
Register eax1 is only used once, in a load instruction, never in a store instructionBounds checking is only performed on store instructionsAnnotation: No work for mmStrata on first load instruction above, as eax1 metadata is dead
July 24, 2008 | NICECAP Site Visit46
Software Exploit Prevention and Remediation via Software Memory Protection
Detecting Redundant Metadata
Some instructions cause mmStrata to fetch metadata that is the same “numeric” tag that already exists for the registershl eax,2 ; eax1 := eax0 << 2 (numeric)mov eax,[ebx+eax] ; eax2 := [ebx1+eax1]
If the type inference system determines that eax2will be numeric, then there is no work for mmStratato do for the second instruction
– No point in having even one instruction of instrumentation to put “numeric” in the metadata for eax; it is already numeric
July 24, 2008 | NICECAP Site Visit47
Software Exploit Prevention and Remediation via Software Memory Protection
Informative Annotations for Recovery
Prototypes 5-6 include adaptive feedback and recoveryRecovery policies need to put certain values into the registers that are live when the vulnerable function returnsStatic analyzer emits an annotation for each function that gives the type (numeric or pointer) for each register at function return
July 24, 2008 | NICECAP Site Visit49
Software Exploit Prevention and Remediation via Software Memory Protection
Prototype 5 Operation
Program binary
Stratafier (offline)
Program binary
Entry point
apache executable
Entry point
mmStrata binary
(runtime)
apache executable (protected)
Static Analyzer (offline)
Annotations file
(read at runtime)
RuntimeOffline
mmStrata library
Profiler (offline)
optional
Adaptive feedback
July 24, 2008 | NICECAP Site Visit50
Software Exploit Prevention and Remediation via Software Memory Protection
Goals
Recovery– Continue executing the program once attack detected– Possibly allow reduced level of service
• slower performance• reduced functionality
Adaptive Feedback– optimize performance – reduce false positives– enable better recovery mechanism
July 24, 2008 | NICECAP Site Visit51
Software Exploit Prevention and Remediation via Software Memory Protection
Recovery Mechanisms
Current Mechanisms– Ignore bogus writes– Force “return error” from function with bogus write
• Similar to throwing an exception• Unwind the stack frame and continue execution
In the works– Unwind more than 1 stack frame– Once a function is attacked, future executions can track memory
writes and un-wind those as well• More expensive protection, but can prevent DOS attacks!
July 24, 2008 | NICECAP Site Visit52
Software Exploit Prevention and Remediation via Software Memory Protection
Recovery Example: Ignoring writes
char *readString(char *s) {for (;;) {
c = fgetc(f);if (c == EOF)
return NULL; if (c == '\n')
return s;s[i] = c;i++;
}}
What happens when S overflows?
char *readString(char *s) {for (;;) {
c = fgetc(f);if (c == EOF)
return NULL; if (c == '\n')
return s;if( InBounds(I,s))
s[i] = c;i++;
}}
writes ignored, S returned
side effect: S not null terminated.
July 24, 2008 | NICECAP Site Visit53
Software Exploit Prevention and Remediation via Software Memory Protection
Recovery Example: Force return
char *readString(char *s) {for (;;) {
c = fgetc(f);if ((c == EOF))
return NULL; if (c == '\n'))
return s;s[i] = c;
i++;}
}
What happens when S overflows?
char *readString(char *s) {for (;;) {
c = fgetc(f);if ((c == EOF))
return NULL; if (c == '\n'))
return s;if( InBounds(I,s))
s[i] = c;else
return 0;i++;
}}
return immediately with 0side effect: characters left in buffer
Which policy works for a given program and what parameters do we use? Solution: Adaptive Feedback!
July 24, 2008 | NICECAP Site Visit54
Software Exploit Prevention and Remediation via Software Memory Protection
Adaptive Feedback (Ongoing)
Detect working Recovery/Repair mechanisms– Monitor after recovery process for fault– Search recovery-mechanisms for one that “works” on a per-pc basis
Verify Profiler Information– False positive or attack? – Monitor optimizing annotations derived from the profiler
• slower• more accurate• detects when optimizing annotation is wrong (false positive
results), and can return to faster protection afterwards
Components for feedback system mostly complete– Ongoing: incorporate components into complete system– Ongoing: evaluation
July 24, 2008 | NICECAP Site Visit55
Software Exploit Prevention and Remediation via Software Memory Protection
AF Example: Verifying Profiler Informationchar *PrintIfNonNull(int *s) {
if(s)printf(“%d”, *s);
}
mov eax, [ebp + 4]cmp eax, $0jeq L1mov [esp+0], $”%d”mov eax, [eax]mov [esp+4], eaxcall printf
L1: ret
always numeric
mmStrata Optimization
false positiveverify profilerevoke always numeric annotation
July 24, 2008 | NICECAP Site Visit56
Software Exploit Prevention and Remediation via Software Memory Protection
Recovery/Adaptive Feedback Summary
Continued performance benefits through hybrid static/dynamic analysis, continued profilingProfile-driven, online-verified optimizations to determine false positives vs. attacksTwo recovery policies working with various parametersAdaptive feedback mechanism detect over-optimistic optimizations, recovery policy parameters
July 24, 2008 | NICECAP Site Visit58
Software Exploit Prevention and Remediation via Software Memory Protection
Non-malicious Client Request
Unprotected Server
Proposal submitting
institution
We are UVA. Was our latest
proposal awarded funding?
Unprotected Operation
July 24, 2008 | NICECAP Site Visit59
Software Exploit Prevention and Remediation via Software Memory Protection
Malicious Client Request
Unprotected Server
Proposal submitting
institution
We are UVA. Was our latest
proposal awarded funding?
Unprotected Operation
July 24, 2008 | NICECAP Site Visit60
Software Exploit Prevention and Remediation via Software Memory Protection
Malicious Client Request
mmStrata
Protected Server
Proposal submitting
institution
We are UVA. Was our latest
proposal awarded funding?
Protected Operation
July 24, 2008 | NICECAP Site Visit62
Software Exploit Prevention and Remediation via Software Memory Protection
Metrics
How will we know when success is achieved?– Benchmark testing– Benchmark timings
Measurements– False negatives
• Not detecting an exploit when it should be detected– False positives
• Detecting an exploit, when there is none– Performance
July 24, 2008 | NICECAP Site Visit63
Software Exploit Prevention and Remediation via Software Memory Protection
False Negatives (April 2008)None in scope (coarse grained) for prototypes 1+2Fine-grained exploits are in scope for prototypes 3+4Case study: global fields
struct ASI {int valid;float (*pt2func)(float, float);int buf[128];int *uid_ptr;
}–No false negatives detected–Fine-grained test cases difficult to find and create
July 24, 2008 | NICECAP Site Visit64
Software Exploit Prevention and Remediation via Software Memory Protection
False Positives(Feb. 2008)
150vpr.route_log
1100vpr.place_log
119vortex.vortex
1851twolf.test
9694perlbmk.test
0122parser.test
000mesa.mesa
000mcf.inp
001gzip.compressed
4931800gcc.cccp
359064gap.test
0180equake.inp
0102bzip2.input.random
000art.test
000ammp.ammp
HeapStackStaticBenchmark.Input
Pre-decremented constantsStrength ReductionByte ops on ptrsEarly Pointer Initialization
July 24, 2008 | NICECAP Site Visit65
Software Exploit Prevention and Remediation via Software Memory Protection
False Positives
0
5
0
3
10
0
3
6
9
12
Feb-08 Coarse-grained Optimizations Feedback Fine-grained
SPEC
Pro
gram
s
State of the art
July 24, 2008 | NICECAP Site Visit66
Software Exploit Prevention and Remediation via Software Memory Protection
Runtime Overhead
150 64 150 150 83 63 31
~300~400
0200400600800
100012001400
Static
Protec
tion
Opts1
Opts 2
Proto1
Heap Pro
tectio
nStac
k Pro
tectio
n
Opts 3
Proto 2
Opts 4
Jul-0
8
Slow
dow
n (ti
mes
nat
ive
exec
utio
n) ~3800
Prior state of the art: 38x
July 24, 2008 | NICECAP Site Visit68
Software Exploit Prevention and Remediation via Software Memory Protection
How Difficult are Memory Overwriting Exploits?
We can quantify the reduction in attack possibilities due to SMPAll exploits have a source (e.g. a buffer or pointer, whether in heap, stack or global static data)
– Source is accessible to attacker (e.g. input buffer)
Each exploit has at least one overwriting target (e.g. a return address, data pointer, function pointer, argument passed to system call)
– SMP greatly reduces possible overwriting targets
July 24, 2008 | NICECAP Site Visit69
Software Exploit Prevention and Remediation via Software Memory Protection
Reduction of Memory Overwriting Targets
The possible memory overwriting targets are all variables, fields within variables, return addresses, saved frame pointers, and heap allocation data structuresWe first quantify how the SMP coarse-grained defense reduces the available targetsGoal: At least an order of magnitude (10X) reduction in memory overwriting targets
July 24, 2008 | NICECAP Site Visit70
Software Exploit Prevention and Remediation via Software Memory Protection
Quantifying Memory Overwriting TargetsWe define the following variables and then analyze their typical values:
A = # of activation records (active stack frames)G = # of global static variablesH = # of active heap allocationsL = average # of local variables per activation recordGF = average # of fields per global variableHF = average # of fields per heap allocation
We assume that the attacker can target any variable or field in the running programTargets for attacker input into a heap buffer:
2*A + A*L + H*HF + H + G*GF
July 24, 2008 | NICECAP Site Visit71
Software Exploit Prevention and Remediation via Software Memory Protection
Reduction in Attack Surface
Targets for attacker input into an unprotected heap buffer:
2*A + A*L + H*HF + H + G*GFExplanations2*A return address and saved frame pointerA*L all local variables in the active programH*HF all heap variables and fieldsH all (hidden) heap control structuresG*GF all global variables and fields
July 24, 2008 | NICECAP Site Visit72
Software Exploit Prevention and Remediation via Software Memory Protection
Reduction in Attack Surface cont’dTargets for attacker input into a heap buffer (not protected by SMP):
2*A + A*L + H*HF + H + G*GFAfter SMP coarse-grained defense is applied:
HFIs the reduction in targets an order of magnitude (10X)?Worst-case values gathered from benchmarks:
(2*10+10*3.6+5*20+5+3400*1.2) reduced to 20(20+36+100+5+4000) = 4161 reduced to 20 (>200X)
Typical (instead of worst case): >1000X
July 24, 2008 | NICECAP Site Visit73
Software Exploit Prevention and Remediation via Software Memory Protection
How Difficult are Fine-Grained Exploits?The previous calculations assume that fine-grained targets still exist (i.e. fields within the heap allocation containing the input buffer)
struct stupid { // strange coding style here !<critical function pointer field here>char buf[200]; // vulnerable input buffer<critical data item here>
};
The fine-grained defenses of SMP will detect scaled or indirect accesses to the buffer, and direct accesses to the most likely critical target fieldsProfiling run is likely to exercise this code, because user input paths are very likely to be taken in profiling runs
July 24, 2008 | NICECAP Site Visit75
Software Exploit Prevention and Remediation via Software Memory Protection
SMP Innovations
General design Synergy of static and dynamic analysisState of the art in solving disassembly problemsFirst dynamic memory monitor to protect all memory regions (stack, heap, static)Profiler-based data granularity inferenceAdaptive feedback scheme to fine tune optimization and false positive reductionOngoing remediation work
July 24, 2008 | NICECAP Site Visit77
Software Exploit Prevention and Remediation via Software Memory Protection
Milestones and Progress
ID Task Name Start FinishQ3 07 Q3 08Q1 08Q4 07Q2 07 Q2 08
MarFebAugJun DecNovJul Oct JanMay Sep
18/31/20075/7/2007Prot. 1: Coarse
grained Static Data2
11/30/20079/3/2007Prot. 2: Coarse
grained Stack/heap
33/28/200812/3/2007Prot. 3: Fine grained
Stack & Static Data
4 5/2/20083/31/2008Prot. 4: Fine grained Heap
8 9/5/20089/3/2007Optimization
9 5/2/20089/3/2007Improving Granularity
5 7/4/20085/5/2008Adaptive learning scheme
6 9/5/20087/7/2008Repair and recovery
710/3/20089/8/2008Evaluation and
documentation
Apr May Jun Jul Aug Sep
July 24, 2008 | NICECAP Site Visit78
Software Exploit Prevention and Remediation via Software Memory Protection
Progress Since Last PI MeetingAt Chicago PI meeting: demonstrated Prototype 2
– Complete coarse-grained defense– Early prototype 3 work was leading to many false positives
Prototypes 3-5 are now complete– Granularity extended without false positive explosion– Profiler tool among the major enhancements to the SMP infrastructure– A large majority of all prior exploits in the field were coarse grained and
would be prevented by SMP Prototype 2– Granularity extensions raise the bar even higher for attackers
Optimization of run time overhead has shown steady progress (from 55X to 31X) and will continueAdaptive scheme and recovery have been implemented and are continuing to be enhanced
July 24, 2008 | NICECAP Site Visit79
Software Exploit Prevention and Remediation via Software Memory Protection
Summary of Expenses
$54,733January 2008$552,437April – December 2007
$875,536TOTAL$64,606May 2008$67,454April 2008$65,980March 2008$69,300February 2008
AmountMonth
July 24, 2008 | NICECAP Site Visit80
Software Exploit Prevention and Remediation via Software Memory Protection
Staff Responsibilities
Stratafier tool work by Ann Bailey, Jason Hiser, and Mark BaileyStatic Analyzer: Clark Coleman; design consultation provided by Mark Bailey and Jack DavidsonProfiler: Michele Co and Jason HisermmStrata (the Memory Monitor SDT): Jason Hiserwith heap memory portion assisted by Michele CoEvaluation, including development of exploits test suite: Michele Co, Nicholas Williams, Anh Nguyen-Tuong, with consultation provided by John Knight and David Evans
July 24, 2008 | NICECAP Site Visit81
Software Exploit Prevention and Remediation via Software Memory Protection
Impact of SuccessPractical protection for large class of vulnerabilities
– General techniques for software memory protection– Efficient
Source code not required– Legacy apps, COTS, GOTS, 3rd party libraries,
outsourced/offshored SW
Migration path to “safe” software Reduces urgency of installing vendor patches
– Enables administrators to thoroughly test and vet patches– No Zero-Day attacks
Provides NIC with analysis capabilitiesResearch Impact
– Novel blend of static and dynamic analysis techniques– Novel application of virtual machine technology
July 24, 2008 | NICECAP Site Visit82
Software Exploit Prevention and Remediation via Software Memory Protection
Ongoing and Future Work
User Interface– Policy choice (e.g. coarse or fine grained, use profiler or not;
exploring others)– Precise diagnostic output for exploits– Forensic tools (e.g. browser for annotations file)
Optimization– Interprocedural analysis– Enhanced memory location tracking and type inference– Simplified bounds checking annotations– Statically proving that bounds checking is not needed in some cases
July 24, 2008 | NICECAP Site Visit83
Software Exploit Prevention and Remediation via Software Memory Protection
Ongoing and Future Work cont’d
Granularity– How fine can we make the granularity without incurring false
positives?– How much profiler work can be assumed by the static analyzer?
Remediation– Open problem in the research community
Porting SMP to other platformsAnalyzing shared libraries/DLLsWhat are the priorities of iARPA?
July 24, 2008 | NICECAP Site Visit84
Software Exploit Prevention and Remediation via Software Memory Protection
Technology Transfer & Activities
UVa Patent Foundation– Licensing of related technology (anti-tampering, execution of
static/dynamic encrypted binaries) to financial consulting company
Academic– Strata virtual machine in use at other research institutions
Industrial– Raytheon (Integrated Defense Systems): experimental evaluation on
internal applications
National Intelligence Community– Would like to work with iARPA in identifying potential customers and
applications
July 24, 2008 | NICECAP Site Visit85
Software Exploit Prevention and Remediation via Software Memory Protection
Find vulnerable program input locations
Find critical data items that could be overwritten
Record annotations to guide runtime SDT monitoring of input & critical data
Ultra-efficient software dynamic translator analyzes and translates instructions at run time
Static Binary Analyzer annotations guide attack detection and remediation
Atta
ck
Res
ilien
ce