University of Maryland

Securing Programs by Continuous Address Space

Randomization

Tugrul Incetugrul@cs.umd.edu

PD Week ’13

University of Maryland 2

Code Layout• Software and hardware have evolved to

run programs fasto Optimizing compilerso Complex code transformationso Inliningo Packed code layout

• Execution environments are very stricto Every piece of code occupies a predetermined locationo Each module has a fixed address at runtimeo Hard to modify executables

University of Maryland

Problems with Code Layout• Intrusion attacks benefit from strict

program layoutso Attackers guess locations of critical functions

• Function locations are constant for non-PIE executables

• Relative distances between functions are constant even in shared librarieso Current randomization techniques only change the base

address

• Very sensitive to information leakage3

University of Maryland

A Typical Function Call

4

buffer

Saved RBP

Saved RIPargN

…

arg1

CurrentFunc.

…

void currentFunc() { … foo(arg1, …, argN); …}

void foo(int arg1, …, int argN) { char buffer[64]; scanf(“%s”, buffer); … return;}

int system(char* cmd) { // run cmd}

foo

University of Maryland

Return-Programming Attack

5

buffer

Saved RBP

Saved RIPargN

…

arg1

CurrentFunc.

…

Maliciouscommand

…&system()

…

…&buffer

void currentFunc() { … foo(arg1, …, argN); …}

void foo(int arg1, …, int argN) { char buffer[64]; scanf(“%s”, buffer); … return;}

int system(char* cmd) { // run cmd}

foo

University of Maryland

void currentFunc() { … foo(arg1, …, argN); …}

void foo(int arg1, …, int argN) { char buffer[64]; scanf(“%s”, buffer); … return;}

int system(char* cmd) { // run cmd}

Return-Programming Attack

6

buffer

Saved RBP

Saved RIPargN

…

arg1

CurrentFunc.

…

Malicious command

…&system()

…

…&buffer

I need to guess the location of system() and where return address is

stored

foo

University of Maryland

Preventing Attacks• Address Space Layout Randomization

(ASLR)o Conventional approacho Rebase executable files (including shared libraries)

• ASLR has many limitationso One randomization constant for the whole executable

− If attacker learns one address in the executable, s/he knows the full map

o Randomization constant fixed during execution− Allows multiple tries (brute-force)

o No randomization for child processes− Attackers might have unlimited identical processes to attack

7

University of Maryland

Entropy with ASLR• ASLR promises high entropy

o 40-bits of entropy on patched kernels• Actual entropy is much less

o All executables are loaded at addresses that start with 0x00007f----------o Executables are loaded very close to each othero Least-significant 12-bit-offset of a function address is constant

8

0 0 00 7 F A B C X 1 2 3

12-16 bits

University of Maryland 9

NINJA System Overview• NINJA: No Intrusion by Jumping Around

• Rewrite executables with completely relocatable functions

• Link with a first-party runtime relocator

Executable Relocatable Executable

Binary Rewriter

execution foo

foo'

Relocator

University of Maryland

Completely Relocatable Functions

• Position independent code (PIC)o Dependent on location after initial relocation of executableo Relative addressing

• Remove dependencies to locationo Instruction-pointer based addressingo Calls with

− absolute addresses− relative addressing

o Table-based branches

10

University of Maryland

Editing the Executable• Instruction-pointer based addressing

• Updating offsets is impractical

• Why not use a constant instead of the instruction-pointer?o No need to update the offset

11

Target

Offse

t

InstructionInstruction??? mov 0x0, 0x100(%rip)

University of Maryland

Editing the Executable• Our constant: initial location of the

functiono Store this value on stacko All IP-based addresses are updated to use this new value and a

modified offset− (IP + Offset) = (<Initial Function Location> + Offset’)− mov 0x0, 0x100(%rip) mov 0x0, 0x80(%r15)

• Shared Librarieso This constant initially depends on the instruction-pointero During first relocation, it is replaced with a real constanto No modification of code for relocation after the first one

12

University of Maryland

Editing the Executable• Function Table

o Calls go through this tableo Updated at runtime

• Table-based brancheso Table contains only offsetso Add instruction-pointer to offsets to determine target

13

Initial Location

Current Location

Execution Count

Active Call Count Size

Block 2

jmp *raxBlock 1

Block 3

Block 4

Offset to Block 1Offset to Block 2Offset to Block 3Offset to Block 4

University of Maryland 14

Editing the Executable• Accessing parameters on stack

o Need to update offsets to rsp / rbp

Return Addr.

…

Parameter

Prev Func. Frame

Initial Func. Loc.

Prev. Frame Ptr.Stack

Ptr.

• Add call to Relocator at function exit

University of Maryland

Runtime Relocation Strategy• Relocate individual functions

o Randomly after a given time interval (R)o After they execute N times

• How to pick a reasonable N?o N = 1 : relocate after every function execution

− High overheado N = 10,000 : infrequent relocation

o Adaptive Strategy: Pick N with respect to execution frequency

− Profiling data− High N for functions that execute often− Low N for functions that execute rarely

15

University of Maryland 16

Experimental Evaluation• Linux (Ubuntu 11.04)

o Maximum 28-bits of entropy

• Measurementso Overhead using benchmarks from SPEC CPU 2006o Time for successful attack using a modified version of Apache

HTTP Server

University of Maryland

Runtime Performance

17

No Relo

cation

N=10,00

0

N=1,000

N=100

N=10

Adap

tive

11.5

22.5

33.5

44.5

5Normalized Running Time

Various Relocation Frequencies

University of Maryland

Attacks on NINJA• ASLR with PIE: Attacks take an average of

4.9 hourso Range: 16 seconds to more than 14 hours

• NINJA: low probability of successful attacko Probability of a successful attack in i tries is given by:

18

𝑃 𝑎𝑡𝑡𝑎𝑐𝑘 (𝑛 )=1−(1− 1𝐴𝑇

𝐹𝑅𝐸𝑁(𝑅+𝐸𝑁 ) )

𝑖

N Threshold for relocationR Random Relocation Interval

F Number of FunctionsE Average execution time of a functionA Total number of addresses to tryT Time each attack for an address

takes

University of Maryland 19

1 32102

4

32767.

9999

99999

9

104857

6

335544

32

107374

1824

343597

38367.

9999

109951

162777

60

0.2

0.4

0.6

0.8

1

Fixed: Near Target Fixed: Far TargetASLR NINJA

Number of Tries (logarithmic scale)20 25 210 215 220 225 230 240235

Probability of Successful Attack

University of Maryland 20

Successful Attack Probability in 24 hrs

0.0000%

0.0007%

0.0119%

0.1907%

NINJA ASLR

241681Elapsed Time (hours)

Prob

abili

ty o

f Suc

cess

ful A

ttac

k (l

og s

cale

)

University of Maryland 21

Runtime Overhead with Relocation

N=InfiniteN=10,000

N=1,000N=100

0%

20%

40%

60%

80%

R=Infinite

R=100R=25

R=1

R=Infinite R=100 R=25 R=1

Relocation throughExecution Count Relocation at

Timed Intervals

University of Maryland

Conclusion• Strict layout of code makes programs

vulnerable

• Process functions to be completely relocatable

• Relocate functions at runtimeo After Nth executiono Periodically at timed intervals

• Attackers cannot identify function locations on time to attack

22