Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR Dmitry Evtyushkin*, Dmitry Ponomarev*, Nael Abu-Ghazaleh§, * § The 49th Annual IEEE/ACM International Symposium on Microarchitecture October 18, 2016 Taipei, Taiwan

Buffer Overflow & Code Injection Data Stack: str2 [ret address] str1 = &(str2) Stack frame for vulnerable() vulnerable.c vulnerable(char*str1) { char str2[100]; strcpy(str2, str1); return; } Protection: W^X, NX-bit, etc. – Mark pages either writable or executable – But not both

Reuse Instead of Injecting Code Key Idea: Reuse executable or library code instead of code injection Programs use standard libraries, e.g. glibc Attacker can return to functions in libraries e.g. system() Programs have huge code base with versatile code Attacker can combine this code into desired code Bypass NX protection

Code Reuse Attacks (CRA) Attacker Code: Data Stack: xor ecx,ecx; mul ecx; lea ebx,[esp+8]; mov al, 11; int 0x80; ret; A B C D E Stack Pointer Code Pages: A B B D C E D E C A

How to Protect from Code Reuse? Address Space Layout Randomization (ASLR) Randomize position of important structures including code segment and libraries ASLR can be applied to both User space and Kernel space Implemented on all modern Operating Systems Bypass Return-to-libc, Return-Oriented Programming and Jump-Oriented programming (JOP) attacks

How ASLR Works Where are my gadgets? ret; xor ecx,ecx; A mul ecx; Attacker Code: Data Stack: xor ecx,ecx; mul ecx; lea ebx,[esp+8]; mov al, 11; int 0x80; ret; A B C D E Stack Pointer Code Pages: A B B D C E D E C A

Kernel ASLR Similar attack applies to OS Kernel The attacker can make the kernel to jump to arbitrary address The attacker needs to know kernel code layout

Bypassing ASLR The attacker can rely on other attacks to bypass ASLR: Memory disclosure attacks to leak pointers e.g. Dangling Pointer Use side channels to find out code layout e.g. Shared cache or Branch predictor

Overview of Jump-over-ASLR Attack Use Branch Target Buffer (BTB) to recover random address bits Two scenarios: One user space process attacking another User process attacking Kernel ASLR Attack capabilities: Recover all random bits in Linux Kernel and KVM* Recover part of random bits in User Process making brute force attack much faster * https://github.com/felixwilhelm/mario_baslr/

Attack principals (User-Level) Victim Spy BTB Address tag Target A: jmp A: jmp A B B: B: C: Observation: MISPREDICTION Observation: HIT

Latencies Observed by the Spy Percentage Latency (in cycles)

Looking for BTB Collisions Victim Spy Observations: jmp 86ms *no contention* 87ms *no contention* 100ms 89ms *no contention* *COLLISION DETECTED* jmp

Latencies Observed by the Spy

Limitations Not all address bits are used for BTB addressing This makes possible collisions in higher and lower halves of address space

Attack Principals (OS/VMM-Level) OS Space Attack Principals (OS/VMM-Level) BTB A: jmp 0xffffa9fe8756 9fe8756 Address tag Target User Space B: B: jmp A: C: 0x0000a9fe8756 9fe8756 Collision: match address tag, not target

KASLR in Linux Result: full KASLR bits recovery in about 60 ms

Latencies Observed by the Spy

Attack Conclusion Partial recovery bits in User-Level programs due to BTB addressing scheme Full fast recovery KASLR bits in Linux kernel and KVM New side channel attack makes current ASLR schemes insecure

Proposed Mitigation Techniques Software Mitigations Randomize more KASLR bits requires reorganization of kernel memory space Fine-grained ASLR: randomize at function, block, instruction level Performance implications Requires recompilation Hardware Mitigations KASLR: prevent user and kernel space collisions User-Level: make unique BTB mappings for each process

Questions?