software exploit prevention and remediation via …clc5q/smp/mergedslides24jul2008-v2.pdfsoftware...

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



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)



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



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



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



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)



Final SMP Operation (simplified)

Program binary

Offline Processing

Program binaryapache

executable

mmStrata binary

(runtime)

apache executable (protected)

RuntimeOffline

Adaptive feedback



Prototype 5 Operation

Program binary

Stratafier (offline)

Program binary

Entry point

apache executable

Entry point

mmStrata binary

(runtime)


Static Analyzer (offline)

Annotations file

(read at runtime)

RuntimeOffline

mmStrata library

Profiler (offline)

optional

Adaptive feedback


Memory Monitor Strata

Jason D. Hiser




Program binary


Program binary

Entry point

apache executable

Entry point

mmStrata binary

(runtime)



Annotations file

(read at runtime)

RuntimeOffline

mmStrata library

Profiler (offline)

optional

Adaptive feedback



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



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



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



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



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?



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



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


Dynamic Profiler Tool

Jason Hiser




Program binary


Program binary

Entry point

apache executable

Entry point

mmStrata binary

(runtime)



Annotations file

(read at runtime)

RuntimeOffline

mmStrata library

Profiler (offline)

optional

Adaptive feedback



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



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



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



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



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



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



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



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



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



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)


Static Analyzer

Clark Coleman




Program binary


Program binary

Entry point

apache executable

Entry point

mmStrata binary

(runtime)



Annotations file

(read at runtime)

RuntimeOffline

mmStrata library

Profiler (offline)

optional

Adaptive feedback



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



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



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



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



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



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



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


Merged


IndirectIndirectIndirectIndirectIndirectIndirectIndirectDirectDirectDirectDirect

Merged



Granularity Annotations

Instructions 1 and 2 get no annotation; Instruction 3 can access all indirect bytes



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



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



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!



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



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



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



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


Program Recovery and Adaptive Feedback

Jason D. Hiser




Program binary


Program binary

Entry point

apache executable

Entry point

mmStrata binary

(runtime)



Annotations file

(read at runtime)

RuntimeOffline

mmStrata library

Profiler (offline)

optional

Adaptive feedback



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



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!



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?


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.



Recovery Example: Force return


c = fgetc(f);if ((c == EOF))

return NULL; if (c == '\n'))

return s;s[i] = c;

i++;}

}

What happens when S overflows?


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!



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



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



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


Prototype Demonstration

Michele Co



Non-malicious Client Request

Unprotected Server

Proposal submitting

institution

We are UVA. Was our latest

proposal awarded funding?

Unprotected Operation



Malicious Client Request

Unprotected Server

Proposal submitting

institution



Unprotected Operation



Malicious Client Request

mmStrata

Protected Server

Proposal submitting

institution



Protected Operation


Evaluation and Metrics

Michele Co



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



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



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



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



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


Difficulty of Exploits

Clark Coleman



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



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



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



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



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



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


Summary of Research Innovations

Jack Davidson



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


Schedule, Finances, and Technology Transfer

Jack Davidson



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



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



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



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



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



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



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?



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



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

software exploit prevention and remediation via …clc5q/smp/mergedslides24jul2008-v2.pdfsoftware...

Documents