Address Space Layout Permutation Chongkyung Kil Systems Research Seminar 10/06/05
Overview Problem Description Current Approaches Limitations of Current Approaches Solution Evaluation Limitations Conclusions and Future Work
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
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
Ad-hoc Solutions Static Analysis Dynamic Analysis MOPS, CQUAL, SLAM, etc Dynamic Analysis StackGuard, PointGuard, Taintcheck, etc. Most target specific type of known attacks
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
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
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
Randomization Examples Fig 1. Normal Process Memory Layout Fig 2. PaX ASLR Process Memory Layout
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%
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
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
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)
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
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
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
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
ASLP Implementations Object Reference Fig 3. Object Reference Example
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
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)
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
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)
ASLP Implementations: User Level Fig 6. PLT & GOT Before Permutation Fig 7. PLT & GOT Before Permutation
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)
Demonstration of Permutation Fig 8. Normal Process Memory Layout Fig 9. Process Layout after Coarse-grained Permutation with ASLP Kernel
Demonstration of Permutation < Before the permutation > < After the permutation > Fig 10. Example of Fine-grained Permutation (Data Segment)
Security Evaluation Randomness example: 220 possible locations/2 = 524K average guesses needed
Security Evaluation 152 Guesses Per Second
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
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%
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
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
Questions? Thank you for coming