G E N E S I S : A Framework For Achieving Component Diversity

GENESIS: A Framework For Achieving Component Diversity

John C. Knight, Jack W. Davidson, David Evans, Anh Nguyen-TuongUniversity of Virginia

Chenxi WangCarnegie Mellon University

University of Virginia www.cs.virginia.edu/genesis

DARPA SRS January 2005 PI Meeting 2

Overview Technical objectives

Develop tools and techniques for introducing diversity automatically

Formulate theoretical underpinnings of diversity Perform realistic evaluations of the developed techniques

Existing practice in diversity Traditional diversity is expensive

Done manually Duplicate development and application resources

Effectiveness not fully understood Difficult to reason about Realistic evaluation difficult



Overview Technical approach

Introduce diversity at compile, link, and execution time Use automatic program transformation techniques Use close coupling of compiler and software dynamic translator to

explore novel diversity techniques Major risks and mitigation

Unacceptable overhead Unconvincing evaluation Susceptibility to new class of attacks Mitigation

Development of theoretic framework Optimization of SDT

Quantitative metrics Seed “important” applications with vulnerabilities (known and

synthetic) Measure overhead of the diversity techniques



Overview Expected major achievements

New framework for achieving practical and effective diversity Defenses against Web application exploits Prototype implementations demonstrating the effectiveness of the

framework Task schedule with milestones

6/30/2005 Improved Strata VM performance Combination of compile-time and run-time transformations Prototype defenses against web application attacks Attacks against

ISR and potential defenses Modeling Demonstration

12/31/2005 Combination of compile-time, run-time, and course-grained source-

level diversity Comprehensive evaluation of all techniques Demonstration



Dynamic diversity

Advantages Binary only (no source needed) Wide range of transformations

possible Transformations can be applied

(or reapplied) at any point during execution

Handles untrusted code (libraries, third party components)

Prevents exploitation of both unintentional and intentional software vulnerabilities

Disadvantages Can degrade performance Debugging difficult Accountability

Use software dynamic translation (SDT) to introduce diversity into applications



Software Dynamic Translation

Application Binary

CPU

Dynamic TranslatorOS

Layer of software between application binary and the OS/CPU

Application’s instructions are examined and modified before being executed on the CPU

Uses: Binary migration: Transmeta’s Code

Morphing, FX!32, Virtual PC, Daisy, … Emulation and simulation: Embra,

Shade,… Optimization: Dynamo,

Dynamo/RIO, Mojo,… Emerging domains: security, low

power, code compression, systems prototyping,…



Modern SDT Systems Daisy

Daisy: Dynamic compilation for 100% architectural compatibility, Ebcioglu and Altman, 24th Annual International Conference on Computer Architecture, 1997

DynamoDynamo: A transparent dynamic optimization system, Bala, Duesterwald, and Banerjia, PLDI 2000,

FX!32FX!32: A profile-directed binary translator, Chernoff, Herdeg, Hookway, et al, IEEE Micro 18(2), 1997.

StrataRetargetable and Reconfigurable Software Dynamic Translation Scott, Kumar, Velusamy, et al. CGO 2003.Strata: A Software Dynamic Translation Infrastructure, Scott and Davidson, WBT 2001, Barcelona, Spain, 2001.



Strata

Infrastructure for building SDT systems Promotes code reuse by providing

common implementation environment for SDT

Highly reconfigurable for rapid prototyping of translators

Easily retargeted to new platforms, and already supports SPARC/Solaris, MIPS/IRIX, x86/Linux,

PowerPC/MacOS



Strata

Fragment Cache

i nst1

i nst2

…i nst

x

i nst3

i nst4

cmpl %eax, %ecxt r ampol i ne

Code Fragment1

i nst7

i nst8

…t r ampol i ne

Code Fragment2

Context Switch

Fetch

Decode

Translate

New PC

Finished?

No

Strata Virtual Machine

Yes

Context Capture

Cached?

Yes

New Fragment

Next PC

i nst1

i nst2

…i nst

x

j mp L2i nst

y

…L2: i nst

3

i nst4

cmpl %eax, %ecxbne L4i nst

5

i nst6

…j mp L8

L4: i nst7

i nst8

…

Application Text

CFn

CFn+1

CFn+2

CFn+3

CFn+4

CFn+5

CFn+x

i nst5

i nst6

…t r ampol i ne

Code Fragment3



Using the Strata Framework

Application Binary

CPU

Dynamic Translator

OS

ContextSwitch

Cached?

Finished?

ContextCapture

NewFragment

Fetch

Next PC

Translate

Decode

NewPC

custom_fetch(Address pc) { if (is_on_stack(pc)) { fail(“Smash!”); } else { return fetch(pc); }



Strata diversity transformations

Default diversity Address space

randomization Code is relocated in F$ Run-time stack is

modified Control-flow randomization

Basic block structure is modified (no unconditional branches, direct function calls are eliminated)

Indirect jumps and calls transformed

Fragment Cache

i nst1

i nst2

…i nst

x

i nst3

i nst4

cmpl %eax, %ecxt r ampol i ne

Code Fragment1

i nst7

i nst8

…t r ampol i ne

Code Fragment2

Context Switch

Fetch

Decode

Translate

New PC

Finished?

No


Yes

Context Capture

Cached?

Yes

New Fragment

Next PC

CFn

CFn+1

CFn+2

CFn+3

CFn+4

CFn+5

CFn+x

i nst5

i nst6

…t r ampol i ne

Code Fragment3



Instruction Set Randomization

Encrypt application code prior to execution Decrypt code before it is executed Malicious code that is injected through some

software vulnerability will be decrypted but because it was not encrypted, the resulting code, will not execute properly

See Randomized Instruction Set Emulation to Disrupt

Binary Code Inject Attacks, Barrantes, Ackley, Forrest, et. al, CCS 03.

Countering Code-Injection Attacks with Instruction-set Randomization, Kc, Keromytis, Prevelakis, CCS 03.



Implementing ISR with Strata

Diablo

M1.o

M2.o

Application binary modules

Secure key

0f e3ac82…34b2d712652f…

L2: 3782a31423ba21d3d3d2b14e…ef 9d

L4: 3d3ff 32e…

Context Switch

Fetch

Decode

Translate

New PC

Finished?

No


Yes

Context Capture

Cached?

Yes

New Fragment

Next PC

Encrypted Application

custom_fetch(Inst i) { return decrypt(i);}

glibc.a

crt0.o

Runtime libraries modules

Link time Run time



Issues

SDT Issues Overhead

Run-time overhead Extra code executed Context switches

Memory Overhead Recovery Attacking the SDT Debugging Accountability



Strata Overhead (x86/Linux)

0

1

2

3

4

5

6

7

8

9

10

gzip vp

rgc

cm

cf

craf

ty

pars

er

perlb

mk

gap

vorte

xbz

ip

Benchmark

Slo

wd

ow

n (

No

rma

lize

d t

o N

ati

ve

Ex

ec

uti

on

)

Base Strata

IBTC

Shared IBTC

Adaptive IBTC

Adaptive IBTC+ FastReturns



Strata Overhead (x86/Linux)

Strata adds about 434K overhead (static)

F$ is limited to 4 MB Large enough to run all SPEC and Apache

without a F$ flush Size overhead is generally not an issue



Issues

ISR-specific issues When to encrypt Effect of executing random instructions Ineffective against attacks that do not

involve code injection Strength of encryption technique



Effectiveness of ISR

Nora Sovarel and David Evans Where’s the FEEB?



How secure is ISR? Shacham et. al. [CCS 2004] presented a

brute force attack on memory address space randomization 24-bit effective key space

Can a similar attack be constructed against instruction set randomization? Larger key space (32 bits - 4K bytes) Need to attack in fragments Need a way to tell if fragment guess is

correct



Answer:

Slows down an attack about 26 minutes

Under the right circumstances…



Requirements Need a vulnerability

Any buffer overflow vulnerability will do Must know the exact memory location

Must be able to crash server (lots of times) without re-randomization Possible if server handles requests by forking

processes (e.g., Apache) Need to know if server crashes

Socket open between attack client and server



Jump Attack: Make Infinite Loop

Vuln

era

ble

Buff

er

Overwritten Return Address

0xEB (Jump)0xFE (-2)

Unkn

ow

n M

ask

s

Corre

ct Guess

Guessing first 2 byte masks

216 Possibilities

Need about 212 guesses to learn first 2 bytes



Incremental Jump AttackV

uln

era

ble

Buff

er



Unkn

ow

n M

ask

s

Corre

ct Guess

Guessing first 2 byte masks



Gu

ess

ed

Mask

s

Guessing additional byte masks: < 256 attempts

0xCD (INT)



False Positives – Bad News Incorrect guesses might produce same

behavior as correct guess Injected bytes demask to instruction that

produces indistinguishable behavior e.g., conditional jump inst often behaves like

jump Injected bytes demask to “harmless”

instruction, and subsequently executed instruction is (or behaves like) correct guess

One incorrect mask guess will probably disrupt attack code



False Positives – Good News

Can distinguish correct mask using other instructions

Try using guessed mask to inject a harmless one-byte instruction


0x90 (NOP)0xEB (Jump)0xFE (-2)

Gu

ess

ed

Mask

s



False Positives – Better News

Structure of false positives can be used to make guessing more efficient Conditional jump instructions (e.g., JP/JNP) Opcodes 0x70-0x7E are all conditional jumps All are complementary pairs:

0x7 0bxyz not taken 0x7 0bxyz is taken! 32 guesses that try all values of first 4 bits

and last bit always find an infinite loop Need more guesses to determine correct mask

Need up to 25+8 guesses to get first 2 bytes



Scaling the Attack Once we have learned enough masks:

Use near jump to return location instead of creating infinite loops

Fill subsequent instructions with 0xCD bytes 0xCD 0xCD is interrupt instruction guaranteed to

crash

Package attack code: don’t need to obtain enough masks to hold entire worm, just enough to hold decrypting micro-VM



Extended Attack


Gu

ess

ed

Mask

s

0xE9 (Near Jump)0xCD (INT)0xCD (INT)0xCD (INT)0xCD (INT)

0xCD (INT)0xCD (INT)

0xEB (Jump)

0x0632

-bit

off

set

(to

jum

p to

or

igin

al

retu

rnad

dres

s)“C

rash Zone”

Expected work:< 16 attempts to find first jumpinginstruction

~ 8 attempts to determine correct mask



Experiments Implemented attack against constructed

vulnerable server protected with RISE [Barrantes et. al, 2003] Memory space randomization works!

Turned off Fedora’s address space randomization Needed to modify RISE

Ensure separate processes use same randomization key (other proposed ISR implementations wouldn’t need this)

Able to obtain correct key most of the time

8 bytes: 99% 1024 bytes: 85%



Results

0

5000

10000

15000

20000

25000

30000

35000

Ave

rage

Num

ber

of A

ttem

pts

Key Bytes Acquired (log scale)

2 8 16 64 1024

Jump Attack

Return Attack

< 31,000 attempts (26 minutes)to acquire 1024 key bytes

255 attempts (50 seconds)

to get first byte

1

Jump Attack

First 2 bytes:2027 attempts / byte

Next 14 bytes:222 attempts / bytes

Next 1008 bytes:23.25 attempts / byte



Solutions Attack depends on being able to determine

key from one known ciphertext-(likely) plaintext pair (trivial with XOR) Use block cipher or permute ISA to make this hard Strata’s fragment cache makes this possible

Attack depends on being able to launch multiple attack attempts against the same key Re-randomize and restart after any process crash

(enables easy denial-of-service) Re-randomize frequently (without restarting)



Improved ISR Use AES

Symmetric-key block cipher that can use keys of 128, 192, or 256 bits and encrypts in blocks of 128 bits (16 bytes)

Compiler and Diablo cooperate to align all branch targets on 128-bit boundaries Function entry points Pad with no-ops

Unconditional/conditional branch targets Indirect branches Return points

Strata removes no-ops when building fragment (after encryption)



Better ISR

F: inst1inst2inst3bne L1inst5

L1: inst6...

Diablo aligns

3B0x40

0x41

0x42

Address

0x43

0x44

0x45

0x46

0x47

0x48

23

F4

71

3A

21

0x49

0x4A

0x4B

0x4C

0x4D

inst

1

25

DB

3C

bne

4E

inst

2

49

57

0x4E

0x4F

7E

33

67

inst

3

...

inst

4inst

5inst

6

0x50

3B0x40

0x41

0x42

Address

0x43

0x44

0x45

0x46

0x47

0x48

23

F4

71

3A

21

0x49

0x4A

0x4B

0x4C

0x4D

inst

1

25

DB

3C

bne

50

inst

2

49

57

0x4E

0x4F

7E

nop

nop

inst

3

33

inst

4inst

5inst

6

0x50

67

...

Diablo encrypts with AES

128-bit block

130x40

0x41

0x42

Address

0x43

0x44

0x45

0x46

0x47

0x48

45

2B

45

78

FD

0x49

0x4A

0x4B

0x4C

0x4D

inst

1

16

67

38

56

90

inst

2

11

37

0x4E

0x4F

BA

40

C3

inst

3

5E

inst

4inst

5inst

6

0x50

17

...



Better ISR

Diablo

M1.o

M2.o

Application binary modules

Secure key

0f e3ac82…34b2d712652f…

L2: 3782a31423ba21d3d3d2b14e…ef 9d

L4: 3d3ff 32e…

Context Switch

Fetch

Decode

Translate

New PC

Finished?

No


Yes

Context Capture

Cached?

Yes

New Fragment

Next PC

Encrypted Application

glibc.a

crt0.o

Runtime libraries modules

Link time Run time

Decrypt.Engine



DemonstrationApache 1.3.12

CPU (1GHz)

Strata

OS (Redhat Linux 7.3)

ContextSwitch

Cached?

Finished?

Context Capture

New Fragment

Fetch

Next PC

Translate

Decode

NewPC

ghttpd

CPU (1GHz)

Strata

OS (Redhat Linux 7.3)

ContextSwitch

Cached?

Finished?

Context Capture

New Fragment

Fetch

Next PC

Translate

Decode

NewPC

`

...

Firewall

1

3

2

4

Stratified Application (with ISR) + Adapted AttackDisplay

3

1 Native Application + Attack

Stratified Application + Attack2

Stratified Application + Adapted Attack

4

Server Cluster



Learn more about SDT

Tutorial at CGO 2005 (March 20th in San Jose) Profiling Instrumentation Binary translation Security Optimization

Documents

G E N E S I S : A Framework For Achieving Component Diversity