Address Space Layout Permutation

1
Address Space Layout Permutation
Chongkyung Kil
Systems Research Seminar
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
b u f
Exploit!
3 GB
Attack packet
retAddr
retAddr
retAddr
retAddr
NOP
NOP
Attackers code
retAddr
NOP
NOP
5
Ad-hoc Solutions

• Static 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 Attackers 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
b u f
b u f
crash
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
• 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
code
func
Vul func
b u f
15
Dtors Attacks with Coarse-grained
code
data
M A I N
d t o r s
b u f
16
Dtors Attacks with Fine-grained
code
data
M A I N
d t o r s
b u f
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
lt Before the permutation gt
lt After the permutation gt
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
• 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