1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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 *

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

11. Latencies Observed by the Spy
Percentage
Latency (in cycles)

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

13. Latencies Observed by the Spy

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

15. 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

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

17. Latencies Observed by the Spy

18. 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

19. 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

20. Questions?