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

▶
a vulnerable program
SMART_READER_LITE
LIVE PREVIEW

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

Nov 05, 2023 212 likes •672 views

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);

slide-1
SLIDE 1

March 19, 2013

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

Stephen Checkoway and Hovav Shacham

1

1 Monday, April 22, 13

slide-2
SLIDE 2

A vulnerable program

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

2

2 Monday, April 22, 13

slide-3
SLIDE 3

Problem setting

✤ Trusted application: ✤ Untrusted operating system:

3

3 Monday, April 22, 13

slide-4
SLIDE 4

Problem motivation

4

4 Monday, April 22, 13

slide-5
SLIDE 5

Problem motivation

4

4 Monday, April 22, 13

slide-6
SLIDE 6

Problem motivation

4

4 Monday, April 22, 13

slide-7
SLIDE 7

Problem motivation

4

4 Monday, April 22, 13

slide-8
SLIDE 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 Monday, April 22, 13

slide-9
SLIDE 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 Monday, April 22, 13

slide-10
SLIDE 10

The Overshadow approach

7

Application Operating system

Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems. ASPLOS’08

7 Monday, April 22, 13

slide-11
SLIDE 11

The Overshadow approach

7

Application Operating system Hypervisor Shim

Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems. ASPLOS’08

7 Monday, April 22, 13

slide-12
SLIDE 12

The Overshadow approach

7

Application Operating system Hypervisor Shim

Chen et al. Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems. ASPLOS’08

7 Monday, April 22, 13

slide-13
SLIDE 13

Cloaking: T wo views of application memory

8

8 Monday, April 22, 13

slide-14
SLIDE 14

The shim

9

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

✤ Marshals arguments and return values for system calls ✤ Communicates directly with the hypervisor

9 Monday, April 22, 13

slide-15
SLIDE 15

Warmup: A thought experiment

10

Main Apache process Entropy pool

10 Monday, April 22, 13

slide-16
SLIDE 16

Warmup: A thought experiment

10

Main Apache process Entropy pool Workers Workers’ entropy pools getpid() getpid()

⋱

10 Monday, April 22, 13

slide-17
SLIDE 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 Monday, April 22, 13

slide-18
SLIDE 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 Monday, April 22, 13

slide-19
SLIDE 19

Threat model: example

13

asmlinkage long sys_read(unsigned int fd, char __user *buf, size_t count);

User Kernel

buf count

13 Monday, April 22, 13

slide-20
SLIDE 20

Threat model: example

14

asmlinkage long sys_read(unsigned int fd, char __user *buf, size_t count);

User Kernel

buf count

✤ Write arbitrary data, but only inside the supplied buffer ✤ Arbitrary return value

14 Monday, April 22, 13

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

slide-22
SLIDE 22

Recall our vulnerable program

16

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

16 Monday, April 22, 13

slide-23
SLIDE 23

Step 1: mmap(2)/read(2); normal behavior

17

void *p; p = mmap(4096); read(0,p,4096);

stack heap

17 Monday, April 22, 13

slide-24
SLIDE 24

Step 1: mmap(2)/read(2); normal behavior

17

void *p; p = mmap(4096); read(0,p,4096);

stack heap stack heap

mmap() p

17 Monday, April 22, 13

slide-25
SLIDE 25

Step 1: mmap(2)/read(2); normal behavior

17

void *p; p = mmap(4096); read(0,p,4096);

stack heap stack heap

mmap()

stack heap

read() p p

17 Monday, April 22, 13

slide-26
SLIDE 26

Step 1: mmap(2)/read(2); malicious behavior

void *p; p = mmap(4096); read(0,p,4096);

stack heap

18 Monday, April 22, 13

slide-27
SLIDE 27

Step 1: mmap(2)/read(2); malicious behavior

void *p; p = mmap(4096); read(0,p,4096); p

stack heap

mmap()

stack heap

18 Monday, April 22, 13

slide-28
SLIDE 28

Step 1: mmap(2)/read(2); malicious behavior

void *p; p = mmap(4096); read(0,p,4096); p p

stack heap

mmap()

stack heap

read()

stack heap

18 Monday, April 22, 13

slide-29
SLIDE 29

Step 2: Standard I/O; normal behavior

✤ fgetc() ✤ fgets() ✤ fread() ✤ fscanf() ✤ getc() ✤ getchar() ✤ getdelim() ✤ getline() ✤ gets() ✤ scanf() ✤ vfscanf() ✤ vscanf() ✤ …

19

stack heap stack buf heap

mmap()

stack buf heap

read()

19 Monday, April 22, 13

slide-30
SLIDE 30

Step 2: Standard I/O; malicious behavior

✤ fgetc() ✤ fgets() ✤ fread() ✤ fscanf() ✤ getc() ✤ getchar() ✤ getdelim() ✤ getline() ✤ gets() ✤ scanf() ✤ vfscanf() ✤ vscanf() ✤ …

20

stack heap

mmap()

stack heap buf

read()

stack heap buf

20 Monday, April 22, 13

slide-31
SLIDE 31

Step 3: LibC’s malloc

✤ 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

size+1 top

21 Monday, April 22, 13

slide-32
SLIDE 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 + 4

22

22 Monday, April 22, 13

slide-33
SLIDE 33

malloc(n) example

  • 1. nb ← n + 4 rounded up to a multiple of 8 bytes

23

23 Monday, April 22, 13

slide-34
SLIDE 34

malloc(n) example

  • 2. Determine the start of the heap via brk system call

24

S,E

❷

24 Monday, April 22, 13

slide-35
SLIDE 35

malloc(n) example

  • 3. Increase the size of the heap via brk

25

S,E

❷

S E

❸

25 Monday, April 22, 13

slide-36
SLIDE 36

malloc(n) example

  • 4. Increase the size again to maintain 8-byte alignment via brk

26

S,E

❷

S E

❸

S E

?

❹

26 Monday, April 22, 13

slide-37
SLIDE 37

malloc(n) example

  • 5. If step 4 failed, determine the end E of the heap (last brk’s return value)

27

S,E

❷

S E

❸

S E

?

❹

S E

❺

27 Monday, April 22, 13

slide-38
SLIDE 38

malloc(n) example

  • 6. Carve off a chunk of size nb

28

S E

❸

S E

?

❹

S E

❺ ❻ ❷

S

nb

E

E - S - nb

28 Monday, April 22, 13

slide-39
SLIDE 39

malloc(n) example

  • 7. Write the size E - S - nb of the remaining top chunk at S + nb + 4

29

S E

❸

S E

?

❹

S E

❺ ❻ ❷ ❼

S

nb

E

E - S - nb

29 Monday, April 22, 13

slide-40
SLIDE 40

Attacking the lower half

30

S

nb

E

E - S - nb

30 Monday, April 22, 13

slide-41
SLIDE 41

Attacking the lower half

  • 1. Choose S such that S + nb + 4 is the address of a saved return address

30

S

nb

E

E - S - nb

application code/data libc application stack E - S - nb + 1

30 Monday, April 22, 13

slide-42
SLIDE 42

Attacking the lower half

  • 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

S

nb

E

E - S - nb

application code/data libc application stack E - S - nb + 1

gets()

30 Monday, April 22, 13

slide-43
SLIDE 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 Monday, April 22, 13

slide-44
SLIDE 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 Monday, April 22, 13

slide-45
SLIDE 45

Thank you

33

Fin

33 Monday, April 22, 13