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