A vulnerable program #include <stdlib.h> int main() { void - PowerPoint PPT Presentation

I AGO A TTACKS : W HY THE S YSTEM C ALL API IS A B AD U NTRUSTED RPC I NTERFACE Stephen Checkoway and Hovav Shacham March 19, 2013 1 Monday, April 22, 13 1

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

Problem setting ✤ Trusted application: ✤ Untrusted operating system: 3 Monday, April 22, 13 3

Problem motivation 4 Monday, April 22, 13 4

Problem motivation 4 Monday, April 22, 13 4

Problem motivation 4 Monday, April 22, 13 4

Problem motivation 4 Monday, April 22, 13 4

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 Monday, April 22, 13 5

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 Monday, April 22, 13 6

The Overshadow approach Application Operating system Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting 7 Protection in Commodity Operating Systems. ASPLOS’08 Monday, April 22, 13 7

The Overshadow approach Application Shim Operating system Hypervisor Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting 7 Protection in Commodity Operating Systems. ASPLOS’08 Monday, April 22, 13 7

The Overshadow approach Application Shim Operating system Hypervisor Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting 7 Protection in Commodity Operating Systems. ASPLOS’08 Monday, April 22, 13 7

Cloaking: T wo views of application memory 8 Monday, April 22, 13 8

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’08 9 Monday, April 22, 13 9

Warmup: A thought experiment Entropy pool Main Apache process 10 Monday, April 22, 13 10

Warmup: A thought experiment Entropy pool Main Apache process getpid() ⋱ getpid() Workers’ entropy pools Workers 10 Monday, April 22, 13 10

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 Monday, April 22, 13 11

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 Monday, April 22, 13 12

Threat model: example asmlinkage long sys_read(unsigned int fd, char __user *buf, size_t count); count User Kernel buf 13 Monday, April 22, 13 13

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 Monday, April 22, 13 14

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 Monday, April 22, 13 15

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

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

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

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

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

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

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

Step 2: Standard I/O; normal behavior ✤ fgetc() ✤ fgets() stack stack stack ✤ fread() ✤ fscanf() ✤ getc() ✤ getchar() mmap() read() ✤ getdelim() buf buf ✤ getline() ✤ gets () ✤ scanf() ✤ vfscanf() ✤ vscanf() heap heap heap ✤ … 19 Monday, April 22, 13 19

Step 2: Standard I/O; malicious behavior ✤ fgetc() ✤ fgets() stack stack stack ✤ fread() buf buf ✤ fscanf() ✤ getc() ✤ getchar() mmap() read() ✤ getdelim() ✤ getline() ✤ gets () ✤ scanf() ✤ vfscanf() ✤ vscanf() heap heap heap ✤ … 20 Monday, April 22, 13 20

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 Monday, April 22, 13 21

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 + 4 22 Monday, April 22, 13 22

malloc(n) example 1. nb ← n + 4 rounded up to a multiple of 8 bytes 23 Monday, April 22, 13 23

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

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

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

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 Monday, April 22, 13 27

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

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

Attacking the lower half nb E - S - nb E S 30 Monday, April 22, 13 30

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

Attacking the lower half gets() application code/data libc application stack nb E - S - nb E - S - nb + 1 E 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 Monday, April 22, 13 30

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 Monday, April 22, 13 31

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 Monday, April 22, 13 32

Thank you Fin 33 Monday, April 22, 13 33