Diversity Algorithms for Worrisome Software and Networks (DAWSON)

Diversity Algorithms for Worrisome Software and Networks

(DAWSON)

James Just, Mark Cornwell, Jason Minto, Art TorreyGlobal InfoTek, Inc.

Karl Levitt, Jeff Rowe, Tufan DemirUC Davis

R. SekarConsultant (SUNY Stony Brook)

27 January 2005

Overview• Project overview

• Integration framework

• Diversity to break exploits

• Diversity to break payloads

• Framework for analyzing effectiveness

• Binary rewriting review

• Next steps

Problem Space (1) Excessive Homogeneity => Systemic Vulnerability

• Attacks exploit dense environment with ease to spread fast and/or far

• Foreseeable cyber-risks dominated by static, durable monoculture of executables

How prevent exponentially cascading failures?

Problem Space (2) Common Mode Failures Impede Intrusion

Tolerant Systems

• Intrusion tolerant systems are:– Expensive– Have large hw/sw footprints– Assume a priori knowledge of

attack modalities

• Success depends on availability of spare components– Assumption of independent intrusions/faults is flawed– Availability of diverse commercial spares limits

effectiveness even if intrusion tolerance system affordable – Rapid learning of attack signatures for blocking is hard– Custom N-version programming is costly

DAWSON Approach• Randomized transforms of Windows executables at

runtime – Preserve functionality of executable modules (e.g., dll)– Transform binary code, machine addresses, names, etc– Use annotations to facilitate– Pseudo-random numbers produce unique transformations

on each application restart– Network protocol diversity effort replaced by breaking

payload execution• Goal: Beat program metric by 10X for large fraction

of exploit space if transforms are focused– 100 functional equivalents with no more than 3 susceptible

to same exploit as baseline code for most exploits– Low overhead transforms (runtime performance)

Memory corruption attacks

Corrupt a pointer valueCorrupt target of existing pointerCompromise security critical data• File names opened for write or execute• Security credentials -- has the user

authenticated himself?

Corrupt data pointer• Frame pointer• Local variables, parameters• Pointer used to copy input

Corrupt code pointer• Return address• Function pointer• Dynamic linkage tables (GOT, IAT)

Pointer to injected data

Pointer to existing data• Example: corrupt string arguments to functions so that they point to attacker desired data already in memory, e.g., “/bin/sh”, “/etc/passwd”

Pointer to injected code

Pointer to existing code

Attack Space of Interest: Memory Error Exploits

Includes common buffer overflows, strncpy(), off-by-one, cast screw-up, format strings, double-free, return to libc, other heap structure exploits

Evaluation• Identify assumptions and ROE for possible

Red Teaming

• Internal testing with– Fabricated applications with known vulnerabilities

and exploits– Real applications with known vulnerabilities and

exploits

• Possible use of Emulab or Deter network emulation testbeds

Some Assumptions & Red Team ROEs

• Attacks are remote, automated and non-directed

• Attacker cannot observe the execution of valid programs without using system calls

• Processes cannot transition from user mode to kernel mode without using system calls

• Attacker cannot automate non-trivial static analysis of memory contents

• Modification is limited to binary (or memory) editing; source code is unavailable

Status• Interim products

– Native Windows (MFC, .Net) PE File Editor– Transforms

• Automated permutation of the Import Address Table in PE files• Automated replacement of DLL names and functions with random strings

in PE files• Local variable location modification – not quite automated yet

– In-process• Reordering of binary code blocks and insertion of dead code blocks• Asymmetric transformation of function parameters using dummy

functions.

• New insights on requirements– Address obfuscation (to defeat trivial static analysis of memory)– Fail-crash & detection mechanism (to defeat brute force trial and error)– Non-by-passability of transform mechanisms – Balzer wrapper

mechanism – UC Davis investigating option from another project– Because of perceived higher value, shifted some effort to developing

diversity to break payloads rather than diversity for network protocols

Transition and Future Work• Interim use intermediate products by other

SRS contractors• Integrate with follow-on projects/products• If successful

– Package for military users– Possible GITI “commercial” product– Possible open source “toolkit” approach– Transition to Microsoft or other software vendors– Some expressions of VC interest

• Standard research publications

Baseline Tasks

1. Requirement Refinement

2. Exploit Diversification

3. Payload Diversification

4. Integration

5. T&E

6. Program Mgt.

Prototypes

FY04 FY05 FY06

Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4Q2

1 2 3

DAWSON Project Schedule & Milestones

Current Attack

Problem

SoftwareSpecification

SourceCode

ExecutableCode

Machine-levelCode

Loader

KnownV-Spec

Exploit & Payload

Machine CodeSpecification

Vulnerability

Vulnerability Specification?• All aspects of a program execution which can

be exploited by malicious code to gain control of the Program Counter, e.g.,– Memory Topology– Stack Specification– System APIs– Application API’s– Libraries– Exception Handling– Etc

Machine-levelCode

Machine-levelCode

Machine-levelCode

Machine-levelCode

Machine-levelCode

Machine-levelCodeMachine-level

Code


Code


Code

Machine-levelCode

Machine-levelCode

SoftwareSpecification

SourceCode

ExecutableCode

Machine-levelCode

TransformingLoader

V-Spec Unknown Until Load-Time

Breaking the V-Spec

TransformSpecifications

Machine-levelCode

KnownV-Spec

Exploit & Payload

Vulnerability

Vulnerability??Doesn’tMatch

X

Machine CodeSpecification

Transform Techniques in Literature*• Obfuscation

– Layout obfuscation (scramble identifiers, remove comments, change formats)– Control flow obfuscations (Statement grouping, ordering, computation, opaque constructs)– Data obfuscation (Storage, encoding, grouping, ordering)– Preventative transformations (prevent decompilers from operating by exploiting weaknesses)

• Inherent (aliases, variable or bogus dependencies, opaqueness side effect & difficulty)• Targeted

• Source code– N-version programming– Functional-behavior preserving diversity in components used (e.g., different encryption algorithms,

different scales for data such as Celsius or Fahrenheit)– Semantics preserving source code transformations

• Place sensitive data (such as function and data pointer) below the starting address of any buffer• Variable ordering• Equivalent instructions

– Variable compilation --Variable internal names, padding and addresses, linking orders– Insertion of opaque constructs or other dead code to change memory layout

• Binary code– Address transformations (relative and absolute) on binary code

• Randomize base address of memory regions (Stack, Heap, DLL, routines/static data in executable)• Permute order of variable/routines (Local variables in stack frame, static variables, routines in shared libraries or

routines in executables)• Introduce random gaps between objects (Padding in stack frames, between successive malloc allocation requests,

between variables in the static area; Gaps within routines and add jump instructions to skip over gaps)– System resource, system call, or DLL name/address transformation– Instruction set transformation

• Static and dynamic binary rewriting

*References shown on later slides

Multi-Layer Defense Strategy

Prevent Remote Exploit of Memory ErrorsPrevent Remote Exploit of Memory Errors

Prevent Injected Code from Properly ExecutingPrevent Injected Code from Properly Executing

Prevent Access to Windows DLL’sPrevent Access to Windows DLL’s

Prevent Use of Windows DLL’sPrevent Use of Windows DLL’s

Prevent the Bypass of DLL’sPrevent the Bypass of DLL’s

GITI

GITIUC Davis

UC Davis

Diversity System Functional Architecture:Normal

Original Program

Modified Loader

PRN

Translation

Wrapper

User Inputs

OtherSystem

Resources

Transformed In-memory

program

Normal user inputs are translated

Modified loader transforms original stored program and generates wrapper that retranslates

external calls

AnnotationFile

& untranslated so they work

Diversity System Functional Architecture:Initial Exploit

Original Program

Modified Loader

PRN

Translation

Wrapper

OtherSystem

Resources

Attacker


program

Some attacks fail because

assumed vulnerability

is gone


external calls

AnnotationFile

Diversity System Functional Architecture:Payload Execution

Original Program

Modified Loader

PSN

Untranslation

Wrapper

OtherSystem

Resources

Attacker


program

Other attacks fail because

injected commands are wrong


external calls

AnnotationFile

DAWSON Randomizer

DAWSON Implementation Concept (I)

PE File Editor

PE File Macro Randomizer

PE File Component Randomizers

API

API API API API

PRNG

ProgramAnnotation

File

Original Binary

Program on Disk

Transform Technique 1



o o o

Transform Technique N

Object 1

Object 2

Object 3

o o o

Object K

Modified Binary

Program in Memory or

on disk

Approach eases integration of various transform techniques

DAWSON Implementation Concept (2)

Original B

inary Code

Disassem

bled Code

(Optional) D

ecomiled C

ode

Structure (P

attern) Analyzer

Structure (P

attern) Modifier

(Optional) R

ecompiled C

ode

Reassem

bled Code

Modified B

inary Code

Manual Approach – How best to automate?

DAWSON Implementation Concept (2)

Original B

inary Code

Disassem

bled Code

(Optional) D

ecomiled C

ode

Structure (P

attern) Analyzer

Structure (P

attern) Modifier

Annotation F

ile

Binary Rewriting Randomizer

Modified B

inary Code

Automated Runtime Randomization

Automated Defensive Transformations

Name Source Code

Binary code

Issues/Comments

Control-flow obfuscation ++ + Accurate disassembly

Data obfuscation ++

Permutation/Encryption of parameters

++ + Optimizations in code may obscure parameter passing code

Detection of all memory errors ++ -- May have 20% to 200% overhead

Pointer “encryption” ? -- Difficult to decide (even in source) whether a field is an int or pointer

Instruction set randomization ++ ++ Strong protection from injected code

System call randomization ++ ++ Limited space of randomization

Heapify buffers ++ -- Makes most buffer overflow attacks impossible

Memory layout randomization ++ +

Automated Layout Randomizations

Name Absolute Relative Potential issues

Code, static data in executable

Binary? Source Need relocation information or annotations in binaries.

Code, static data in DLL

Binary Source Range of base addresses for DLLs limited(32K?)

Stack Binary Binary- •Difficulty randomizing data at stack base•Limited range, especially for threads (1M?)

Heap Binary Binary- To fully randomize heap allocations, may need to redefine malloc() implementation

Exploit Breaking Transforms

• Randomize base of stack by a large number (preferably, by 100MB or more for single-threaded programs)

• Randomize locations of installed DLLs– Manage all of the DLLs installed on a system

– Ensure that they get mapped to non-overlapping locations

– Change the mappings periodically

– Need simple management tools to make all of this happen

• Randomize location of functions in the executable.

• Randomize base of the heap and the distance between two successively allocated heap blocks

• Randomize location of static variables in the executable

Transform Characterization

• Type of transformation?

• What object is transformed?

• When can transformation occur?– Pre-load, load, post-load?– Are annotations or compiler support required?

• What types of exploits, payloads are impacted?

• How difficult is implementation of transform?

• Linear Randomization over the Range– 4K Byte Granularity

– Effective address domain approximately 1.0 GB limited by the demands of other process segments.

– Approximate 256K distinct bases are possible

• Two approaches examined*– One approach requires modification of the loader to

implement in the NT-2000-XP environments

– Second approach increase stack reserve space in PE file and decrements ESP – does not require loader modification

Random Stack Rebasing

*Note that stack rebasing can be implemented directly in the PE file for DOS applications

Memory Topology 2 GByte User Space (Win32) typical

Stack Base

Stack R

eserve

.text Segm

ent

Heap R

eserve

.debug Segm

ent

.data Segm

ent

.rdata Segm

ent

Unm

apped Mem

ory

Unm

apped Mem

ory

Stack C

omm

it

Heap C

omm

it

0x000410000x00100000 0x03600000

Randomization Domain

Modifying Static Variable Locations (1)

• Preamble & Postamble code generated by compiler

• Code Block built by developer

• Padding inserted by compiler

PreamblePreamble

Code BlockCode Block

PostamblePostamble

PaddingPadding

• Preamble modified to increase size for local variables

• Code Block modified to use new offsets for local variables

• Postamble stays unchanged

PreamblePreamble

Code BlockCode Block

PostamblePostamble

PaddingPadding

Modifying Static Variable Locations (2)

Example: Original Assembly Code

Preamble

Code Block

Postamble

Padding

Modified Assembly Code

Preamble

Code Block

Postamble

Padding

Diversification of the Windows Vulnerability Environment

Karl Levitt, Hao Chen, Matt Bishop, Zhendong Su, Jeff Rowe, Ivan Balepin, Ebrima Ceesay, Tufan Demir, Bhume

Bhumiratana, Lynn Nguyen, Daisuke Nojiri

UC Davis Computer Security Lab

The Problem

• Microsoft Windows provides the ideal conditions for epidemic cyber-attacks– Plenty of software vulnerabilities (root level buffer

overflows).– Widespread installation of identical software

• Attack prevention in MS Windows is difficult– No protection via compiler modification– No source code for the OS or applications

• A single scripted exploit works against– Any machine– All machines

Diversification of the Windows Vulnerability Environment

• Windows executables typically call API functions for any significant task

• All API functions are provided in DLLs.– Load address of API functions is not known until

the program loads– Load address of API functions varies from host to

host

• Major goal of Windows exploits is to locate the addresses of critical DLL functions

Multi-Layer Defense Strategy

Prevent Remote Exploit of Memory ErrorsPrevent Remote Exploit of Memory Errors

Prevent Injected Code from Properly ExecutingPrevent Injected Code from Properly Executing

Prevent Access to Windows DLL’sPrevent Access to Windows DLL’s

Prevent Use of Windows DLL’sPrevent Use of Windows DLL’s

Prevent the Bypass of DLL’sPrevent the Bypass of DLL’s

Outline• How Code Red and Slammer work• Permute IAT and Change DLL name strings:

Defeat known attacks• Hypothesized attacks that will succeed• Parameter modification: Padding, transformation• Preventing direct system calls from injected

code• Towards quantitative analysis of our approaches• Techniques for binary rewriting• Demonstration

How does DLL system work?

Call *010031A0 01001000

00070000

heap

.text

65D6000000000000

77E80000

kernel32.dllstack

20000000

LoadLibraryA()

010031A0

77E9D961

80000000

77E9D961

IAT`LoadLibraryA’

Code Red Worm

01001000

00070000

heap

.text

00000000

77E80000

kernel32.dllstack

20000000LoadLibraryA()

`KERNEL32’

Injected code77E9D961

EAT

`LoadLibraryA’ 77E9D961

SQL Slammer/Sapphire

01001000

00070000

heap

.text

00000000

77E80000

kernel32.dllstack

20000000LoadLibraryA()

Injected code

77E9D961

sqlsort.dllIAT

77E9D961

Preventing DLL Access• Add Synthetic Diversity to Windows PE

Format– Permutation of the Import Address Table– Random String replacement of DLL names and

functions

Randomize Plain Text Strings

01001000

00070000

heap

.text

00000000

77E80000

kernel32.dll

stack

20000000

LoadLibraryA()

`KERNEL32’

Injected code

77E9D961

EAT

`LoadLibraryA’ 77E9D961

PEB

`KERNEL32’ 77E80000

`a7Ly4SZq19’ 77E80000

Call *010031A0

IAT

`LoadLibraryA’

`a7Ly4SZq19’

`4Cu74xIpI9q2’

`4Cu74xIpI9q2’ 77E9D961

Permute IAT

Call *010031A0 01001000

00070000

heap

.text

65D6000000000000

77E80000

kernel32.dllstack

20000000

LoadLibraryA()

010031A0

77E9D961

80000000

Call *010031A0

0100308C GetProcAddress() 77E90332

77E90332 77E9D961

`LoadLibraryA’

`GetProcAddress’

Call *0100308C

IAT



functions

Some Assumptions…• Attacks are remote, automated and non-directed • Attacker cannot observe the execution of valid

programs without using system calls• Processes cannot transition from user mode to kernel

mode without using system calls• Attacker cannot automate static analysis of memory

contents• Modification is limited to binary (or memory)

editing; source code is unavailable



functions

• Add Diversity to Binary Code– Randomize Base Addresses– Reorder code blocks – Interleave nonfunctional code block

Hypothesis: Operand hijacking

Call *0100308C 01001000

00070000

heap

.text

65D6000000000000

77E80000

kernel32.dll

stack20000000

LoadLibraryA() 77E9D961

80000000PEB

Injected code

0100308C

IAT

77E9D961

Binary Transformation

.text

65D60000

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000

IAT

1

2

3

1

2

3

Binary Transformation

.text

65D60000

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000

IAT

21

2

3

Challenges in Binary Rewriting

.text

65D60000

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000

IAT

1

2

3

JMP EAX

Call EBX

1

2

3

jmp EAX

call EBX

X

Indirect Jumps

Function Pointers

Our Binary Rewriting Approach

.text

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000

IAT

Call 010031A0

cmp eax, ebxjde 6687EF03call 77E9D961jmp 65D833AEcall 77E804AA

77E9D961

jmp 697FA0D6

LoadLibraryA

Preventing DLL Access• What About Brute Force Searches for DLL

Addresses?– Insert code and table entries that point to invalid

addresses → page fault, start over– Attempted execution of inserted dead code blocks

→ dereference null pointer, start over– Landmines: Insert code and table entries pointing

to similar code segments that actually generate alarms

• Other Issues– Insertion of redundant DLL’s– Runtime Diversification

Preventing DLL Access• Key points

– No performance impact upon running programs– Access prevention is policy free

• Challenges– Safety properties of address transformation– Impact of increased program size in memory

Preventing DLL Use• For attacks that locate the proper DLL’s,

diverse transformations prevent their use

• Parameters passed to DLL functions are transformed per machine– Asymmetric parameter value transformation– Additional parameter padding

Function Parameters in Assembly

01001000

.text

65D6000000000000

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000call 77E9D961

77E9D961 IAT

call *010031A0

push EAXpush EBX

push EDIpush EBX

GetProcAddress() mov ECX, EBP+0xcmov EDX, EBP+0x8

Parameter Padding

01001000

.text

65D6000000000000

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000call 77E9D961

77E9D961 IAT

call *010031A0

push EAXpush EBX

push EDIpush EBX

push ECXpush EDX

GetProcAddress()

mov ECX,EBP+0x14mov ECX,EBP+0x10

mov ECX, EBP+0xcmov EDX, EBP+0x8

Asymmetric Parameter Transformation

01001000

.text

65D6000000000000

77E80000

kernel32.dllstack

20000000

010031A0

77E9D961

80000000call 77E9D961

GetProcAddress()

77E9D961 IAT

call *010031A0

push EAXpush EBX

push EDIpush EBX

jmp 00045234cmp EDI, EBXjde 00897EF1

T ans or tio

00045234 r f ma n

Reverse Transformation

mov ECX, EBP+0xcmov EDX, EBP+0x8

Preventing DLL Bypass• Problem: Attacker can provide assembly

components that implement some DLL functions making direct low level (undocumented) Windows system calls

• Trap System Interrupts for Runtime Checking

Signing System Calls by Location

• Post-load pre-execute binary instrumentation

• What is instrumented:– System call ID.

– In Linux system call ID is stored in %eax and interrupt is issued.

– We substitute original syscall_id with signed_id (stored in %eax prior to interrupt)

• Advantage:– Preserve system consistency.

Programs are modified only after they’re loaded.

foo.exe Foo in memoryNormal loadand link

Instrumentin memory

execute

Ek = Fast trapdoor permutation with secret key k.F:{0,1}32 {0,1}24

token = F(Address)%eax = signed_id = Ek(token || syscall_id)

• Address is 32-bit address of the location where system call is made

• syscall_id is only 8 bit (only about 200 syscalls exist in Linux)

Authentication

• Assume: – Non-bypassibility - Every time a program makes system call, we

always intercept it before the kernel. – Memory trace inspection – We need to inspect the stack of the

program.• Method:

– Decrypt the signed_id. • (token || syscall_id) = Dk(%eax) # %eax contains the signed_id

– Inspect the program stack for return address. Compute token of the address:

• check_token = F(Memory[%esp])– If check_token == token, then

• set %eax = syscall_id• Forward the system call to kernel

– Otherwise fail

Limitations• Only authenticate whether system call is made

from original source or not. Attacker can still use library function to do system call.– Possible solution is to inspect further up the stack.

Cross Layer Commonalities

• Address Obfuscation (to defeat trivial static analysis of memory)– Insertion of non-functional blocks– Basic block permutation– Permutation and Insertion of dummy function parameters– Run-time obfuscation

• Fail-crash & Detection Mechanism (to defeat brute force trial and error)– Insert invalid virtual address (page fault)– Execution of dead code (deref. null pointer error)– Deliberate Landmines

Evaluation• Use the DETER Testbed • Based upon the Emulab technology with extra

security controls• On demand large scale testbed for the testing and

evaluation of security tools• Deploy hundreds (thousands) of hosts with diverse

configurations.• Try single attacks against all machines• Red Team could launch automated worm attacks

against all machines

320 Virtual Node Experiment• Each node has its own

OS, filesystem, processes, network interfaces.

• 32 gateways

• 10 hosts per gateway

• Emulate 320 nodes totally

• Colocate factor: 10

• Use 44 physical nodes

Status• We’ve have implemented and demonstrated

diversification of Windows PE format for attack prevention.

• We are implementing the reordering of binary code blocks and insertion of dead code blocks.

• We are implementing the asymmetric transformation of function parameters using dummy functions.

• Investigating potential non-bypassability mechanisms

Probability of Successful Attacks

Pr(A) = Pr(V)/[DE(A) * PEE(A)]

• Success probability of attack A exploiting vulnerability V

• DE denotes “derandomization effort”– Range of randomization of addresses involved in A

– Requires randomization to change after each successful derandomization

• If rerandomization happens after k attempts, multiply Pr(A) by k

• No rerandomization => effect of DE and PEE is additive

• PEE denotes “payload execution effort”– Attempts to successfully execute “attack payload”

• Note: System susceptibility to attacks can be reduced without addressing every vulnerability

What can the injected code do?• DLL access

– Walk PEB to learn base addresses– O(#dlls loaded)– DLLs (except a few) will be renamed, prevent

search by name– Intercept dynamically loaded ones to rename– Can increase the number of loaded dlls

Cont’d• Access to function in DLLS

– Walk IAT of the application• O(#entries in IAT)• Permute the IAT• Can increase the size of IAT

– Add invalid addresses– Scan the code section for call imm_addr

• Replace imm_addr with computed goto• Force static analysis

State-of-Art in Binary Analysis & Transformation

Motivation• No source code needed

– Language-neutral (C, C++ or other)

• Can be largely independent of OS• Ideally, would provide instruction-set independent

abstractions– This ideal is far from today’s reality

• Applications in– Instrumenting long-running programs– Legacy code migration– Program optimizations– Security

• Program obfuscation, security-enhancing transformations

Approaches• Static analysis/transformation

– Binaries files are analyzed/transformed– Benefits

• No runtime performance impact• No need for runtime infrastructure

– Weakness• Prone to error, problem with checksums/signed code

• Dynamic analysis/transformation– Code analyzed/transformed at runtime– Benefit: more robust/accurate– Weakness

• Some runtime overhead• Runtime infrastructure needed

Previous Works (Static)• OM/ATOM (DEC WRL)

– Proprietary and probably outdated

• EEL (Jim Larus et al, PLDI ‘95)– The precursor of most modern rewriters– Targets RISC (SPARC)– Provides processor independent abstractions– Follow up works

• UQBT (for RISC)

• LEEL (for Linux/i386)

Previous Works (Static)• WISA (U. Wisconsin)

– Uses EEL for SPARC– Uses IDAPro+CodeSurfer for x86

• Etch (U. of Washington) [x86/Windows]– Application in performance optimization– Does not seem to be active any more

• PLTO/SOLAR (U. Arizona)– Linux/x86, but has limitations (e.g. static linking)

• Brew (Stony Brook)– Disassembly+RAD implementation

• Various tools for Java– BCEL seems most advanced

Previous Works (Dynamic) • DynInst (U. Maryland, U. Wisconsin)

– Instrumentation of running programs

– Provides OS/architecture independent abstractions for instrumentation

• LibVerify (Bell Labs/RST Corp)– Runtime rewriting for StackGuard

• DynamoRIO (HP Labs/MIT), Strata (UVA)– Disassembles basic blocks at runtime

– Provides API to hook into this process and transform executable

– Used in “Program Shepherding” [USENIX Sec '02]

Most Active Research Groups• WISA project (Wisconsin)

– Somesh Jha, Tom Reps

• DynInst project (Wisconsin/Maryland)– Barton Miller

• SOLAR project (U. Arizona)– Saumya Debray

• DynamoRIO (HP/MIT)– Tool available (binary form), Linux/Win32

• Strata (UVA)– Tool claimed to be available in source form

Most Promising Tools• BREW [Stony Brook]

• DynamoRIO

• IDAPro/CodeSurfer (Commercial)

• DynInst is robust, but capabilities limited for our purpose

• Strata may be good, and is supposedly available in source code, but may not be as mature as DynamoRIO

Phases in Static Analysis of Binaries

• Disassembly

• Instruction decoding/understanding

• Insertion of new code

Questions You Might AskHow many variants does defense require?

100 by contract, but the more the better

Why design in depth?Belt and suspenders, but get multiplicative advantage from multiple

randomization -- hopefully

How do we assure defense achieves multiplicative effect from multiple stages of randomization?From different phenomena:fail-crash (attacker has to retry attack),

independence of stages

How do we achieve multiplicative effect within a stage, e.g., IAT randomization?E.g., prevent attacker from doing DE for a DLL at a time, e.g., Kernel32

Questions You Might Ask (2)How often does defense re-randomize?

Depends on cost of re-randomization (down-time), DE, number of variants needed

What is the cost of randomization?Low for IAT randomization, low for parameter padding, unknown but

determinable for other kinds, e.g., parameter value transformation, return address authentication to prevent system calls from injected code

How does defense do control flow randomization for subtle optimized code?Potentially difficult because static analysis of binary code is hard, but will

accept only sound transformations

Can attacker do de-randomization in payload?Very unlikely

Questions You Might Ask (3)What if attacker obtains defense’s randomization algorithm and

sample randomized code -- known plaintext and cybertext attack?Through static analysis he might generate all variants, but cannot use

them in a payload to compromise more than a fraction of the hosts; this depends on fail crash assumption

Can attacker bypass randomization stages?Hopefully this is achieved only if kernel is not secure

How do we verify this assertion?Careful analysis and lots of testing

Is all this new?Builds on existing obfuscation work, but much is new: defense in depth,

parameter transformation, random space analysis

Questions You Might Ask (4)Do we have the staff to investigate the numerous issues posed?

???

Do we have a plan for all this?Yes!!!

DAWSON Next Steps• Continue developing automated transforms to break

exploits specifications– Implement five key transforms and evaluate cost and

effectiveness– Evaluate alternative annotation approaches and implement– Look specifically at non-buffer overflow attacks

• Continue developing automated transforms to break payload specifications– Prevent brute force searches– Obfuscating code and landmines

• Evaluate integration approaches– PE Editor style v Brew style (v. DynamoRIO style)

• Integrate transforms and test– Pre-loader prefered – Loader hooks, if absolutely required, or DynamoRIO style

Demonstrations Tonight

Thank You!

Backup

Collberg, Thomborson, Low• First systematic studies of Java code

obfuscation– Produced taxonomy (layout, control flow, data,

and preventative transforms)– Low-cost, stealthy opaque constructs– Techniques for obscuring data structures and

abstractions– Measured effectiveness using software complexity

metrics

Wang• Studied malicious host problem to protect trusted probe

communicating with trusted host– Key threats: impersonation, intelligent tampering, input spoofing, not

DOS or random tampering – Input spoofing, in general, unsolvable but

“If spoofing input x requires solving the algortihm-secrecy or execution-integrity problem, then techniques to ensure the later can be used to counteract input spoofing. However, there are applications where this is not possible.”

– Pervasive aliasing enabled proof: precise analysis of transformed program (e.g., CFG) is NP hard

– Replacing 50% of branches =>• Execution time = 4X• Size = 2X

• Wroblewski extended ideas and implemented purely sequential, controllable approach that worked on binary code

Linn and Debray• Rewrote binaries (IA-86) to disrupt major

static disassembly approaches (linear sweep and recursive traversal)– Best commercial tools failed on 65% of

instructions and 85% of functions– Execution times = 1.13 X– Executable size = 1.15-1.20 X

Digital Rights Management• Malicious host is key problem in DRM• White box cryptography approach• Chow et al.

– Notwithstanding Barak, can provide useful commercial levels of security

– Obscured DES and AES algorithms

• Jacobs et al.– Broke obscured DES but showed general problem of

retrieving data from circuits is NP hard

– Admitted that, in practice, usually easy

• Link and Neumann improved on Chow

Barak et al.• Seminal proof showed

– Impossibility of completely obscuring code– No general obfuscator possible

• Badger et al. began to extend Wang’s work– Unable to prove minimum resistance time to

reverse engineering effort– Redirected to review obfuscation work (tour de

force report)

Mitigating Vulnerabilities in Code

• Forrest et al. randomized stack resident data addresses via modified gcc compiler

• Chew and Song randomized stack base address, system call numbers & library entry points via modifying Linux loader and kernel system call table and binary rewriting

• Xu et al. modified Linux kernel to randomize base addresses of program regions

• Approaches still vulnerable to relative address attacks

Forrest et al.• Scrambled executable (prn), then unscrambled

through modified code emulator (x86)– Speed = 1.05 X– Memory usage = 3 X– Discussed danger of generating valid instruction

during scrambling but did not see experimentally

• Kc produced similar results

Bhaktar et al.“Key difference between program obfuscation and address obfuscation is

that program obfuscation is oriented towards preventing most static analyses of a program, while address obfuscation has a more limited goal

of making it impossible to predict the relative or absolute addresses of program code and data. Other analyses, including reverse compilation,

extraction of flow graphs, etc., are generally not affected by address obfuscation”

• Focused on memory error exploits– Randomized absolute/relative addresses in Linux binary

code– Approach offered protection against classic attacks

• Stack smashing, existing code exploits, format string, data modification, heap overflow, double-free, integer overflows

• Data modification attacks still possible but Etoh and Yoda approach could help

Performance of Bhaktar TransformsProgram Combination (1) Combination (2)

% Overhead

Standard Deviation

(% of mean)

% Overhead

Standard Deviation

(% of mean)

tar -1 3.4 0 5.2

wu-ftpd 0 1.4 2 2.1

gv 0 6.1 2 2.1

bison 1 2.0 8 2.3

groff -1 1.1 13 0.7

gzip -1 1.9 14 2.5

gnuplot 0 0.9 21 1.0

Combination 1: link time static relocation of stack, heap and code regions with random gaps in stack frames; Combination 2: load time dynamic relocation of above

Vulnerabilities and Exploits• Aleph One, “Smashing The Stack For Fun And Profit”, Phrack 49, Volume Seven,

Issue Forty-Nine, File 14 of 16, 11/8/1995

• David Litchfield, “Defeating the Stack-Based Overflow Prevention Mechanism of Microsoft Windows 2003 Server”, NGS Research Whitepaper, August 9, 2003, http://www.nextgenss.com/papers.htm

• Mudge, “How To write buffer overflows”, http://www.insecure.org/stf/mudge_buffer_overflow_tutorial.html, 10/20/1995

• w00w00, “Heap Overflow”, http://www.w00w00.org/files/articles/heaptut.txt, 1/1999

• Ryan Permeh, Marc Maiffret, Code Red Disassembly Analysis, eEye Digital Security, http://www.eeye.com/html/advisories/codered.zip.

• Stuart Staniford, Nicholas Weaver, Vern Paxson. “Flash Worms: Is there any Hope?” Silicon Defense, Retrieved 27 March 2003 <http://silicondefense

• Stuart Staniford, Vern Paxson, Nicholas Weaver. “How to Own the Internet in Your Spare Time”, Proceedings of the 11th USENIX Security Symposium. August 2002, Retrieved 27 March 2003, <http://www-dirt.cs.unc.edu/netlunch/fall02/SPW02-worms.htm>

http://www.nextgenss.com/papers.htm

http://www.eeye.com/html/advisories/codered.zip

Software Fault Tolerance & N-version Programming

• A.Avizienis, “Fault Tolerance and fault intolerance. Complimentary approaches to reliable computing”, Proc. 1975 Int. Conf. Reliable Software, Los Angels, CA, Apr 21- 27, 1975, pp 458 - 464

• A.Avizienis, “N-Version Approach to fault tolerant Software”, IEEE-Software eg., vol- SE11, No12, Dec 1985, pp.1491 -1501

• V. Bharathi, “N-Version programming method of Software Fault Tolerance: A Critical Review”, Indian Institute of Technology, Kharagpur 721302, December 28-30, 2003

• L. Chen and A. Avizienis, "N-version programming: A fault-tolerance approach to reliability of software operation," IEEE 8th FTCS, pp. 3-9, 1978

• J.C. Knight and N.G. Leveson, “A Large Scale Experiment In N-Version Programming”, Digest of Papers FTCS-15: Fifteenth International Symposium on Fault-Tolerant Computing, June 1985, Ann Arbor, MI. pp. 135-139.

• J.C. Knight and N.G. Leveson, “An Experimental Evaluation of the Assumption of Independence in Multi-version Programming”, IEEE Transactions on Software Engineering, Vol. SE-12, No. 1 (January 1986), pp. 96-109.

• M.R. Lyu, J.-H. Chen, and A. Avizienis, "Software diversity metrics and measurements," In Proc. The Sixteen Annual Int. Computer Software and Applications Conf. 1992, pp. 69-78.

Obfuscation -- Java Code• C. Collberg, C. Thomborson, and D. Low. “A Taxonomy of Obfuscating

Transformations”. Technical Report 148, Department of Computer Science, University of Auckland, July 1997.

• C. Collberg, C. Thomborson, and D. Low. “Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs” Department of Computer Science, University of Auckland. ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL'98). January 1998

• C. Collberg, C. Thomborson, D. Low. “Breaking Abstractions and Unstructuring Data Structures”, Proceedings of the 1998 International Conference on Computer Languages, pages 28-38. IEEE Computer Society Press. May 1998.

• Larry D’Anna, Brian Matt, Andrew Reisse, Tom Van Vleck, Steve Schwab, Patrick LeBlanc, “Self-Protecting Mobile Agents Obfuscation Report - Final report,” Network Associates Laboratories, Report #03-015, June 30, 2003

• Lee Badger, Larry D'Anna, Doug Kilpatrick, Brian Matt, Andrew Reisse, Tom Van Vleck. “Self-Protecting Mobile Agents Obfuscation Techniques Evaluation Report,” Network Associates Laboratories, Report #01-036, Nov 30, 2001, updated March 22, 2002.

• Douglas Low, Java Control Flow Obfuscation, MS Thesis, Univ. Auckland, 3 June 1998

Obfuscation -- Protecting Software• Boaz Barak, Oded Goldreich, Russell Impagaliazzo, Steven Rudich, Amit Sahai, Salil Vadhan, and Ke

Yang. “On the (im)possibility of obfuscating programs.” In J. Kilian, editor, Advances in Cryptology-CRYPTO ‘01, Lecture Notes in Computer Science. Springer-Verlag.

• Stanley Chow, Philip A. Eisen, Harold Johnson, Paul C. van Oorschot: A White-Box DES Implementation for DRM Applications. Digital Rights Management Workshop 2002: 1-15

• S. Chow, P. Eisen, H. Johnson and P.C. van Oorschot, ``White-Box Cryptography and an AES Implementation'', Proceedings of the Ninth Workshop on Selected Areas in Cryptography (SAC 2002)

• Matthias Jacob, Dan Boneh, and Edward Felten. Attacking an obfuscated cipher by injecting faults , 2002 ACM Workshop on Digital Rights Management. Washington, D.C., 2002

• Hamilton E. Link and William D. Neumann, “Clarifying Obfuscation: Improving the Security of White-Box Encoding”, Sandia National Laboratories, Albuquerque, NM, downloaded from eprint.iacr.org/2004/025.pdf

• Chenxi Wang, “A Security Architecture for Survivability Mechanisms.” PhD thesis, University of Virginia, October 2000.

• Chenxi Wang, "Protection of software-based survivability schemes", in the proceedings of 2001 Dependable Systems and Networks. Gutenburg, Sweden. July 2001.

• w00w00, “Heap Overflow”, http://www.w00w00.org/files/articles/heaptut.txt, 1/1999• Gregory Wroblewski, “General Method of Program Code Obfuscation,” PhD Dissertation, Wroclaw

University of Technology, Institute of Engineering Cybernetics, 2002.• Gregory Wroblewski; “General Method of Program Code Obfuscation,” 2002 International Conference on

Software Engineering Research and Practice (SERP’02), June 24 - 27, 2002, Monte Carlo Resort, Las Vegas, Nevada, USA

• Hamilton E. Link and William D. Neumann, “Clarifying Obfuscation: Improving the Security of White-Box Encoding”, Sandia National Laboratories, Albuquerque, NM, downloaded from eprint.iacr.org/2004/025.pdf

• Cullen Linn, Saumya Debray, “Obfuscation of Executable Code to Improve Resistance to Static Disassembly,” ACM Conference on Computer and Communications Security, Washington DC, October 27-31, 2003.

Source Code Transforms to Mitigate Vulnerabilities

• M. Chew, D. Song. “Mitigating Buffer Overflows by Operating System Randomization,” Technical Report CMU-CS-02-197.

• Hiroaki Etoh and Kunikazu Yoda. Protecting from stack smashing attacks. Published on World-WideWeb at URL http://www.trl.ibm.com/projects/security/ssp/main.html, June 2000.

• Stephanie Forrest, Anil Somayaji, and David H. Ackley. “Building diverse computer systems.” In 6th Workshop on Hot Topics in Operating Systems, pages 67-72, Los Alamitos, CA, 1997. IEEE Computer Society Press.

• Selvin George, David Evens, Steven Marchette. “A Biological Programming Model for Self-Healing”, First ACM Workshop on Survivable and Self-Regenerative Systems (in association with 10th ACM Conference on Computer and Communications Security) October 31, 2003, George W. Johnson Center, George Mason University, Fairfax, VA

• Pax. Published on World-Wide Web at URL http://pageexec.virtualave.net, 2001.• Jun Xu, Z. Kalbarczyk and R. K. Iyer. “Transparent Runtime Randomization for

Security”. Proc. of 22nd Symposium on Reliable and Distributed Systems (SRDS), Florence, Italy, October 6-8, 2003

• StackGuard, Libverify, RAD, PointGuard, MS C++ compiler• Peter Silberman and Richard Johnson, A Comparison of Buffer Overflow Prevention

Implementations and Weaknesses, I-Defense, 1875 Campus Commons Dr. Suite 210 Reston, VA 20191, http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf

http://www.trl.ibm.com/projects/security/ssp/main.html

http://www.trl.ibm.com/projects/security/ssp/main.html

Run-time Transforms to Mitigate Vulnerabilities

• Elena Gabriela Barrantes, David H. Ackley, Stephanie Forrest, Trek S. Palmer, Darko Stefanovic and Dino Dai Zovi, “Randomized instruction set emulation to disrupt binary code injection attacks,” 10th ACM Conference on Computer and Communications Security, Washington DC, October 27-31, 2003.

• Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar, “Address Obfuscation: An Efficient Approach to Combat a Broad Range of Memory Error Exploits,” 12th USENIX Security Symposium, August 2003.

• Gaurav S. Kc, Angelos D. Keromytis, Vassilis Prevelakis, “Countering Code-Injection Attacks with Instruction-Set Randomization,” 10th ACM Conference on Computer and Communications Security, Washington DC, October 27-31, 2003.

CMU Ballista Study• Most production quality operating system and

core library code exhibit large numbers of flaws in validating input, call order, etc.

• Specification-driven testing verifies this result.

SANS Top 10 Top Vulnerabilities to Windows Systems

• W1 Web Servers & Services • W2 Workstation Service • W3 Windows Remote Access Services • W4 Microsoft SQL Server (MSSQL) • W5 Windows Authentication • W6 Web Browsers • W7 File-Sharing Applications • W8 LSAS Exposures • W9 Mail Client • W10 Instant Messaging

SANS Top Vulnerabilities to UNIX Systems

•U1 BIND Domain Name System

• U2 Web Server • U3 Authentication • U4 Version Control Systems • U5 Mail Transport Service • U6 Simple Network Management Protocol (SNMP) • U7 Open Secure Sockets Layer (SSL) • U8 Misconfiguration of Enterprise Services NIS/NFS • U9 Databases • U10 Kernel

Diversity Algorithms for Worrisome Software and Networks (DAWSON)

Documents

Transcript of Diversity Algorithms for Worrisome Software and Networks (DAWSON)