IAGO ATTACKS: WHY THE SYSTEM CALL API IS A BAD UNTRUSTED RPC INTERFACE

Transcription

1 IAGO ATTACKS: WHY THE SYSTEM CALL API IS A BAD UNTRUSTED RPC INTERFACE Stephen Checkoway and Hovav Shacham March 19,

2 A vulnerable program #include <stdlib.h> int main() { void *p = malloc(100); } 2 2

3 Problem setting Trusted application: Untrusted operating system: 3 3

4 Problem motivation 4 4

5 Problem motivation 4 4

6 Problem motivation 4 4

7 Problem motivation 4 4

8 Possible solutions Reimplement in a secure environment (e.g., µkernel) Hardware-based solutions (e.g., XOM processor) Multiple virtual machines (e.g., Proxos) Hypervisor-assisted (e.g., Overshadow) 5 5

9 Possible solutions Reimplement in a secure environment (e.g., µkernel) Hardware-based solutions (e.g., XOM processor) Multiple virtual machines (e.g., Proxos) Hypervisor-assisted (e.g., Overshadow) 6 6

10 The Overshadow approach Application Operating system Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems. ASPLOS

11 The Overshadow approach Application Shim Operating system Hypervisor Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems. ASPLOS

12 The Overshadow approach Application Shim Operating system Hypervisor Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems. ASPLOS

13 Cloaking: Two views of application memory 8 8

14 The shim Marshals arguments and return values for system calls Communicates directly with the hypervisor A majority of system calls can be passed through to the OS with no special handling. These include calls with scalar arguments that have no interesting side effects, such as getpid, nice, and sync. Chen et al. ASPLOS

15 Warmup: A thought experiment Main Apache process Entropy pool 10 10

16 Warmup: A thought experiment Main Apache process getpid() getpid() Entropy pool Workers Workers entropy pools 10 10

17 Technical goals Abstract away details of Overshadow Develop a malicious operating system kernel to attack protected applications Cause the protected application to act against its interests 11 11

18 Threat model Trusted, legacy application Unmodified system libraries Kernel cannot read or modify application state Kernel responds to system calls normally except for return values 12 12

19 Threat model: example asmlinkage long sys_read(unsigned int fd, char user *buf, size_t count); count User Kernel buf 13 13

20 Threat model: example asmlinkage long sys_read(unsigned int fd, char user *buf, size_t count); count User Kernel buf Write arbitrary data, but only inside the supplied buffer Arbitrary return value 14 14

21 Abstraction Malicious kernel (modified Linux) No reading/writing application memory Handle all unsafe system calls correctly Can handle safe system calls maliciously Unmodified user space 15 15

22 Recall our vulnerable program #include <stdlib.h> int main() { void *p = malloc(100); } 16 16

23 Step 1: mmap(2)/read(2); normal behavior stack void *p; p = mmap(4096); read(0,p,4096); heap 17 17

24 Step 1: mmap(2)/read(2); normal behavior stack stack void *p; p = mmap(4096); read(0,p,4096); mmap() p heap heap 17 17

25 Step 1: mmap(2)/read(2); normal behavior stack stack stack void *p; p = mmap(4096); read(0,p,4096); mmap() p read() p heap heap heap 17 17

26 Step 1: mmap(2)/read(2); malicious behavior stack void *p; p = mmap(4096); read(0,p,4096); heap 18

27 Step 1: mmap(2)/read(2); malicious behavior stack stack void *p; p = mmap(4096); read(0,p,4096); p mmap() heap heap 18

28 Step 1: mmap(2)/read(2); malicious behavior stack stack stack void *p; p = mmap(4096); read(0,p,4096); p mmap() p read() heap heap heap 18

29 Step 2: Standard I/O; normal behavior fgetc() fgets() fread() fscanf() getc() getchar() getdelim() getline() gets() scanf() vfscanf() vscanf() stack heap mmap() stack buf heap read() stack buf heap 19 19

30 Step 2: Standard I/O; malicious behavior fgetc() fgets() fread() fscanf() getc() getchar() getdelim() getline() gets() scanf() vfscanf() vscanf() stack heap stack stack buf buf mmap() read() heap heap 20 20

31 Step 3: LibC s malloc top size+1 Split into upper and lower halves Upper half: manages chunks, free lists, handles malloc() and free() Lower half: requests memory from the OS Maintains a top region of unallocated memory from the OS Metadata (including size) inline 21 21

32 The lower half algorithm First call to malloc(n) [creating the top chunk]: 1. nb n + 4 rounded up to a multiple of 8 bytes 2. Determine the start of the heap via brk system call 3. Increase the size of the heap via brk 4. Increase the size again to maintain 8-byte alignment via brk (updates the start S of the heap) 5. If step 4 failed, determine the end E of the heap (last brk s return value) 6. Carve off a chunk of size nb 7. Write the size E - S - nb of the remaining top chunk at S + nb

33 malloc(n) example 1. nb n + 4 rounded up to a multiple of 8 bytes 23 23

34 malloc(n) example 2. Determine the start of the heap via brk system call ❷ S,E 24 24

35 malloc(n) example 3. Increase the size of the heap via brk S E ❸ ❷ S,E 25 25

36 malloc(n) example 4. Increase the size again to maintain 8-byte alignment via brk ❹ S? E S E ❸ ❷ S,E 26 26

37 malloc(n) example 5. If step 4 failed, determine the end E of the heap (last brk s return value) E ❺ S ❹ S? E S E ❸ ❷ S,E 27 27

38 malloc(n) example 6. Carve off a chunk of size nb nb E - S - nb E S ❻ E ❺ S ❹ S? E ❷ S E ❸ 28 28

39 malloc(n) example 7. Write the size E - S - nb of the remaining top chunk at S + nb + 4 E S nb E - S - nb ❻ ❼ E ❺ S ❹ S? E ❷ S E ❸ 29 29

40 Attacking the lower half nb E - S - nb E S 30 30

41 Attacking the lower half application code/data libc application stack nb E - S - nb E E - S - nb + 1 S 1. Choose S such that S + nb + 4 is the address of a saved return address 30 30

42 Attacking the lower half gets() application code/data libc application stack nb E - S - nb E E - S - nb + 1 S 1. Choose S such that S + nb + 4 is the address of a saved return address 2. Choose E such that E - S - nb + 1 is the address of gets() 30 30

43 Step 3: Putting it all together; Iago attack 1. Malicious kernel responds to brk 2. malloc() writes address of gets() over saved return address 3. gets() allocates a buffer via mmap() 4. Kernel returns an address on the stack 5. gets() fills the buffer with read() 6. Kernel responds with a return-oriented program 31 31

44 Conclusions The system call interface is a bad RPC mechanism Malicious kernels can take control of protected applications Options: 1. Design a new system call interface 2. Enable the hypervisor to check the validity of all system calls 3. Paraverification (see the next talk!) 32 32

45 Thank you Fin33 33