RISE : R andom i zation Techniques for Software Se curity

1. RISE: Randomization Techniques for Software Security Dawn Song dawnsong@cmu.edu CMU Joint work with Monica Chew (UC Berkeley)

2. Motivation • Attacker often needs to know system details for exploits • Today’s computer systems are predictable-- makes it easy to exploit vulnerabilities • Randomization Techniques for Software Security • Randomize system internal details • Memory layout • Internal interfaces • Improve software system security • Reduce attacker knowledge of system detail to thwart exploit • Level of indirection as access control • Different from n-version programming (heterogeneity) • Automatic • Relying on internal secrets that attackers do not know

3. RISE: Randomization Techniques for Software Security • Part I: Randomization techniques to mitigate memory safety vulnerabilities • Design choices: • What to randomize • When to randomize • How to randomize

4. Part I: Randomization Techniques to Mitigate Memory Safety Vulnerabilities

5. Memory Safety Vulnerabilities • Memory safety vulnerabilities: • Buffer overruns • Format string vulnerabilities • Integer overflow • Double free • For successful exploit, the attacker needs to know where to jump to, i.e., • Stack layout for stack smashing attacks • Heap layout for code injection in heap • Shared library entry points for exploits using shared library

6. 0x00000000 0x08048000 0x40000000 0xC0000000 0xFFFFFFFF Predictable Memory Layout for Linux Application Process kernel space stack shared library heap bss static data code

7. glibc Randomize Memory Layout (I) • Randomize stack starting point • Modify execve() system call in Linux kernel • Similar techniques apply to randomize heap starting point • Randomize shared library entry points • Approach I: modify execve() system call in Linux kernel • Approach II: remap library function call & binary rewriting during loading or dynamic linking glibc_mod execve(…){ sys_execve(…) } execve(…){ alert(…) } safe_execve(…){ sys_execve(…) } modify

8. Randomize Memory Layout (II) • Work on binaries • Do not need source code • Handle a variety of memory safety vulnerabilities • Buffer overruns • Format string vulnerabilities • Integer overflow • Double free • Simple & Efficient • Problems • Attacks can still happen • Overwrite data • May crash the program • Attacks may learn the randomization secret • Format string attacks • Attacks may bypass the randomization barriers • Utilize instructions in the original code • Approach: randomize code segment • Need better binary-rewriting tools

9. Discussion • Application to other areas: • Randomization in networking • Local services run on different ports Worms have to search through port space as well as IP space • Runtime re-randomize • Restart process & re-randomize process once in a while • Dynamically re-randomize during session • May increase maintenance/debugging overhead in real world

10. Related Work • Forrest et al. [1997] • Randomized compilation • Extension to gcc • Stackguard/Pointguard [Cowan et al.] • Needs source code • Randomize return addresses & pointers • Xu et al. [2003] • Modify dynamic loader • Also randomize GOT (global offset table) • Bhatkar et al. [2003] • Binary rewriting relocating stack & heap starting point • PaX • OpenBSD

11. Conclusion: Randomization techniques for software security • A general principle applying to many different areas • Simple, efficient, complimentary to other techniques • Raises the bar at low cost • Reduce attacker knowledge of system detail to thwart exploit • Level of indirection as (weak) access control