securing programs by continuous address space randomization
DESCRIPTION
Securing Programs by Continuous Address Space Randomization. Tugrul Ince [email protected] PD Week ’13. Code Layout. Software and hardware have evolved to run programs fast Optimizing compilers Complex code transformations Inlining Packed code layout - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/1.jpg)
University of Maryland
Securing Programs by Continuous Address Space
Randomization
Tugrul [email protected]
PD Week ’13
![Page 2: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/2.jpg)
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
![Page 3: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/3.jpg)
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
![Page 4: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/4.jpg)
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
![Page 5: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/5.jpg)
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
![Page 6: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/6.jpg)
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
![Page 7: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/7.jpg)
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
![Page 8: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/8.jpg)
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
![Page 9: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/9.jpg)
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
![Page 10: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/10.jpg)
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
![Page 11: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/11.jpg)
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)
![Page 12: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/12.jpg)
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
![Page 13: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/13.jpg)
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
![Page 14: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/14.jpg)
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
![Page 15: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/15.jpg)
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
![Page 16: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/16.jpg)
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
![Page 17: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/17.jpg)
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
![Page 18: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/18.jpg)
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
![Page 19: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/19.jpg)
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
![Page 20: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/20.jpg)
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
)
![Page 21: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/21.jpg)
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
![Page 22: Securing Programs by Continuous Address Space Randomization](https://reader036.vdocuments.mx/reader036/viewer/2022062501/56816381550346895dd46614/html5/thumbnails/22.jpg)
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