1. Address Space Layout Permutation
Chongkyung Kil
Systems Research Seminar
10/06/05

2. Overview Problem Description Current Approaches
Limitations of Current Approaches
Solution
Evaluation
Limitations
Conclusions and Future Work

3. The Problems: Memory Corruption
Memory Corruption Vulnerability
Popular means to take control of target program
50-80% of US CERT Alerts
Common Memory Corruption Attacks
Buffer overflows, format string exploits, return-to- libc attacks
Successful attacks cause a remote code execution

4. Memory Corruption Attack Example
Stack Frame c o d e r e t a d r e t a d b u f
Exploit!
3 GB
Attack packet:
NOP
NOP
NOP
NOP
Attacker’s code
retAddr
retAddr
retAddr
retAddr
retAddr

5. Ad-hoc Solutions Static Analysis Dynamic Analysis
MOPS, CQUAL, SLAM, etc
Dynamic Analysis
StackGuard, PointGuard, Taintcheck, etc.
Most target specific type of known attacks

6. A Generic Solution: Randomization
Critical Observation
Attackers use absolute memory addresses during the attacks
Nullify Attacker’s Assumption
Makes the memory locations of program objects unpredictable
Forces attackers to guess memory location with low probability of success
Benefit
Protection against known and unknown memory corruption attacks
Downtime better than system compromise

7. Attack Example: With Randomization
Stack Frame c o d e r e t a d r e t a d b u f b u f
crash
3 GB

8. A Generic Solution: Randomization
State-of-the-Art Approaches
Kernel level approaches
Exec-Shield, PaX Address Space Layout Randomization (ASLR)
User level approach
Address Obfuscation

9. Randomization Examples
Fig 1. Normal Process Memory Layout
Fig 2. PaX ASLR Process Memory Layout

10. Limitations of Current Approaches
Kernel Level Approaches
Low entropy: heap 13 bit, mmap 16 bit, stack 24 bit
De-Randomization attack can defeat PaX ASLR in about 4 minutes
Kernel modification required
Pad wastes memory space. Increasing randomness means wasting more memory by pad
Locations of code and data segments can be randomized with PIE
Causes performance overhead (14%)
User Level Approaches
Source-to-source transformation
Wastes memory space by pad
Runtime overhead: 11-23%

11. Solution Goal Address Space Layout Permutation
Increase randomness entropy
Low overhead with negligible pad size
No need of source code modification
Address Space Layout Permutation
A novel binary rewriting tool
Permutes code and data segments with fine-grained randomization
A modified Linux kernel
Permutes stack, heap, and mmap areas

12. Contributions Stronger Protection than Related Works
Provides maximum 29 bits of randomness
Fine-grained randomization on static code and data segments
Low Performance Overhead (less than 1%)
Ease of Use: Automatic Program Transformation
Non-Intrusive Randomization: No Need for Source Code Modification
Only need relocation info in the program

13. ASLP Implementations User Level Address Permutation
Uses binary rewriting technique
Alters base addresses of static code and data segments
Changes orders of functions and variables within the code and data segments
Mitigates partial overwrite attacks, dtors attacks, bss overflow, and data forgery attacks
Kernel level address permutation can not deter these attacks
Works with Linux file format (ELF)

14. Partial Overwrite Attacks
Stack Frame
code r e t a d
Exploit! r e t a d r e t a d
func
Vul
func b u f
3 GB

15. Dtors Attacks with Coarse-grained
Stack Frame
data
code r e t a d r e t a d d t o r s M A I N b u f v a r 1 2 3 4
Exploit!
3 GB

16. Dtors Attacks with Fine-grained
Stack Frame
data
code r e t a d r e t a d d t o r s M A I N b u f v a r 3 1 2 4
3 GB

17. ASLP Implementations Kernel Level Address Permutation
Randomizes the base addresses of stack, heap, and mmap()- ed regions
Mitigates attacks on the stack , heap, and shared library regions
Done by previous work: Chris Bookholt

18. ASLP Implementations
Object Reference
Fig 3. Object Reference Example

19. ASLP Implementations Challenges
What parts of an ELF file need rewriting?
How do we find the correct locations of those parts and rewrite them?
How those parts affect each other during run time?
How to find cross-references between program objects

20. ASLP Implementations Challenges
What parts of an ELF file need rewriting?
Total of 12 sections need to be modified
How do we find the correct locations of those parts and rewrite them?
Use .symtab section (symbol tables and string tables)
How those parts affect each other during run time?
Use relocation sections (e.g. .rel.text, .rel.data)

21. ASLP Implementations: User Level
Two phases: Coarse-grained and Fine-grained Permutation
Coarse-grained Permutation
Relocates static code and data segments
Benefit
Provides 20 bits of randomness to each segment
Coarse-grained Permutation Process
ELF header rewriting: modify the program entry point (e_entry)
Program header rewriting: modify virtual/physical addresses of code and data segments
Section rewriting: modify 12 sections including symbol table, procedure linkage table, global offset table, relocation data

22. ASLP Implementations: User Level
Fig 4. ELF Header and Program Header Before Permutation
Fig 5. ELF Header and Program Header After Permutation
(Move Code Segment by 4KB and Data Segment by 14KB)

23. ASLP Implementations: User Level
Fig 6. PLT & GOT Before Permutation
Fig 7. PLT & GOT Before Permutation

24. ASLP Implementations: User Level
Fine-grained Permutation
Randomly changes the orders of functions and variables in the code and data segments
Benefit
Provides further protections on code and data segments
Fine-grained Permutation Process
Information Gathering: total number of functions and variables, original order and sizes of each function and variable, etc
Random Sequence Generation: two random sequences
Entry Rewriting: re-order the functions and variables
Modify cross-references (relocation sections)

25. Demonstration of Permutation
Fig 8. Normal Process Memory Layout
Fig 9. Process Layout after Coarse-grained Permutation with ASLP Kernel

26. Demonstration of Permutation
< Before the permutation >
< After the permutation >
Fig 10. Example of Fine-grained Permutation (Data Segment)

27. Security Evaluation
Randomness example: 220 possible locations/2 = 524K average guesses needed

28. Security Evaluation
152 Guesses Per Second

29. Performance Evaluation
CPU 2K Benchmark
All kernel level approaches show less than 0.3% including ASLP
Randomizes Stack, heap, and mmap regions
ASLP shows better performance on user level approaches
Randomizes Code and data segments
ASLP (-0.3 %) , PIE (14.38%), Address obfuscation (11%)
LMBench Benchmark
Tests only kernel level approaches (micro benchmarks e.g.context- switching overhead)
ASLP shows 50% better performance compared to other techniques
fork(), exec(), and context-switching

30. Performance Evaluation
Apache Benchmark
Measures the performance of web server
Tests 1 million requests with 100 worker processes
All techniques incur less than 1% overhead
Except PIE: 14%

31. Limitations Information Leakage Protection is Probabilistic
Location information can be leaked
via bugs or format-string attack
Applies to all randomization techniques
Protection is Probabilistic
Brute force de-randomization attack will eventually succeed (e.g. modified return-to-libc attack [20])
With IDS integration, de-randomization could be detected and blocked

32. Conclusions and Future Work
ASLP provides both user/kernel level randomization
ASLP allows users to permute static code and data segments with fine-grained level.
Effectiveness
More randomness, more time to respond to attacks
Low overhead, greater unpredictability
Stack frame layout permutation will add stronger protection

33. Questions?
Thank you for coming