Securing Programs by Continuous
Address Space Randomization
Tugrul Ince
tugrul@cs.umd.edu
PD Week ’13
University of Maryland
Code Layout
• Software and hardware have evolved to run
programs fast
o
o
o
o
Optimizing compilers
Complex code transformations
Inlining
Packed code layout
• Execution environments are very strict
o Every piece of code occupies a predetermined location
o Each module has a fixed address at runtime
o Hard to modify executables
University of Maryland
2
Problems with Code Layout
• Intrusion attacks benefit from strict program
layouts
o Attackers guess locations of critical functions
• Function locations are constant for non-PIE
executables
• Relative distances between functions are
constant even in shared libraries
o Current randomization techniques only change the base address
• Very sensitive to information leakage
University of Maryland
3
A Typical Function Call
…
Current
Func.
arg1
…
argN
Saved RIP
Saved RBP
foo
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
}
University of Maryland
4
Return-Programming Attack
…
void currentFunc() {
…
foo(arg1, …, argN);
…
}
Current
Func.
foo
arg1
…
…
&buffer
argN
…
Saved RIP
&system()
Saved RBP
…
buffer
Malicious
command
void foo(int arg1, …, int argN) {
char buffer[64];
scanf(“%s”, buffer);
…
return;
}
int system(char* cmd) {
// run cmd
}
University of Maryland
5
Return-Programming Attack
…
Current
Func.
foo
arg1
…
…
&buffer
argN
…
Saved RIP
&system()
Saved RBP
…
buffer
Malicious
command
void currentFunc() {
…
foo(arg1, …, argN);
…
}
I need to guess
the location of
void foo(int
arg1, …,
int argN) {
system()
and
char buffer[64];
where return
scanf(“%s”,
buffer);
address
is stored
…
return;
}
int system(char* cmd) {
// run cmd
}
University of Maryland
6
Preventing Attacks
• Address Space Layout Randomization (ASLR)
o Conventional approach
o Rebase executable files (including shared libraries)
• ASLR has many limitations
o 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
University of Maryland
7
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 other
o Least-significant 12-bit-offset of a function address is constant
12-16 bits
0
0
0
0
7
F
A
B
C
X
University of Maryland
1
2
3
8
NINJA System Overview
• NINJA: No Intrusion by Jumping Around
• Rewrite executables with completely
relocatable functions
• Link with a first-party runtime relocator
Relocatable
Executable
Executable
execution
foo
foo'
Binary
Rewriter
Relocator
University of Maryland
9
Completely Relocatable Functions
• Position independent code (PIC)
o Dependent on location after initial relocation of executable
o Relative addressing
• Remove dependencies to location
o Instruction-pointer based addressing
o Calls with
− absolute addresses
− relative addressing
o Table-based branches
University of Maryland
10
Editing the Executable
Target
???
Offset
• Instruction-pointer based addressing
mov 0x0, 0x100(%rip)
Instruction
• Updating offsets is impractical
• Why not use a constant instead of the
instruction-pointer?
o No need to update the offset
University of Maryland
11
Editing the Executable
• Our constant: initial location of the function
o Store this value on stack
o 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 Libraries
o This constant initially depends on the instruction-pointer
o During first relocation, it is replaced with a real constant
o No modification of code for relocation after the first one
University of Maryland
12
Editing the Executable
• Function Table
o Calls go through this table
o Updated at runtime
Initial
Location
Current
Location
Execution
Count
Active Call
Count
Size
• Table-based branches
o Table contains only offsets
o Add instruction-pointer to offsets to determine target
jmp *rax
Block 1
Block 2
Block 3
Offset to Block 1
Offset to Block 2
Offset to Block 3
Offset to Block 4
Block 4
University of Maryland
13
Editing the Executable
• Accessing parameters on stack
o Need to update offsets to rsp / rbp
…
Prev Func.
Frame
Parameter
Return Addr.
Stack Ptr.
Initial Frame
Func. Loc.
Prev.
Ptr.
• Add call to Relocator at function exit
University of Maryland
14
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 overhead
o 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
University of Maryland
15
Experimental Evaluation
• Linux (Ubuntu 11.04)
o Maximum 28-bits of entropy
• Measurements
o Overhead using benchmarks from SPEC CPU 2006
o Time for successful attack using a modified version of Apache
HTTP Server
University of Maryland
16
Runtime Performance
Normalized Running Time
5
4.5
4
3.5
3
2.5
2
1.5
1
No
N=10,000 N=1,000
N=100
N=10
Relocation
Various Relocation Frequencies
University of Maryland
Adaptive
17
Attacks on NINJA
• ASLR with PIE: Attacks take an average of
4.9 hours
o Range: 16 seconds to more than 14 hours
• NINJA: low probability of successful attack
o Probability of a successful attack in i tries is given by:
𝑃𝑎𝑡𝑡𝑎𝑐𝑘 𝑛 = 1 −
1 𝐹𝑅𝐸𝑁
1 −
𝐴𝑇 𝑅 + 𝐸𝑁
𝑖
N
Threshold for relocation
R
Random Relocation Interval
F
Number of Functions
E
Average execution time of a function
A
Total number of addresses to try
T
Time each attack for an address takes
University of Maryland
18
Probability of Successful Attack
Fixed: Near Target
Fixed: Far Target
ASLR
NINJA
1
0.8
0.6
0.4
0.2
0
210
2325
2
1024
10
2
32768
15
2
1048576
20
2
33554432
25
2
1.074E+09
30
2
3.436E+10
35
2
1.1E+12
40
Number of Tries (logarithmic scale)
University of Maryland
19
Successful Attack Probability in 24 hrs
NINJA
ASLR
Probability of Successful Attack (log scale)
0.6554%
0.0410%
0.0026%
0.0002%
0.0000%
1
8
16
24
Elapsed Time (hours)
University of Maryland
20
Runtime Overhead with Relocation
0%-20%
20%-40%
40%-60%
60%-80%
80%
60%
40%
20%
0%
R=1
N=100
R=25
N=1,000
N=10,000
Relocation through
Execution Count
R=100
N=Infinite
R=Infinite
University of Maryland
Relocation at
Timed Intervals
21
Conclusion
• Strict layout of code makes programs
vulnerable
• Process functions to be completely
relocatable
• Relocate functions at runtime
o After Nth execution
o Periodically at timed intervals
• Attackers cannot identify function locations
on time to attack
University of Maryland
22