2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks

Transcription

1

2 Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include injection of malicious code Reasons for runtime attacks Software is written in unsafe languages such as C/C++ Thus, it suffers from various memory-related vulnerabilities Most prominent example: Buffer overflow Are known for 2 decades Various techniques to exploit buffer overflow vulnerabilities have been developed (e.g., Stack Smashing, Heap Overflow, Integer Overflow, Format String) 2

3 3 3

4 BBL 1 entry ins, ins, ins, exit BBL 3 entry ins, ins, ins, exit BBL 2 entry ins, ins, ins, exit BBL 4 entry ins, ins, ins, exit BBL 5 entry ins, ins, ins, exit Entry: Any instruction that is target of a branch (e.g., first instruction of a function) Exit: Any branch (e.g., indirect or direct jump/call, return) 4

5 BBL 1 entry ins, ins, ins, exit BBL 3 entry ins, ins, ins, exit BBL 2 entry ins, ins, ins, exit 1 Code Injection Attacks Malicious Code Shellcode 2 Code Reuse Attacks Library Code BBL 4 BBL 5 Instruction Sequences Library Functions entry ins, ins, ins, exit entry ins, ins, ins, exit Entry: Any instruction that is target of a branch (e.g., first instruction of a function) Exit: Any branch (e.g., indirect or direct jump/call, return) 5

6 6

7 Target of Buffer Overflow Attacks Subvert the usual execution flow of a program by redirecting it to injected (malicious) code The attack consists of 1. injecting new (malicious) code into some writable memory area, 2. and changing a code pointer (usually the return address) in such a way that it points to the injected malicious code Code Injection Code can be injected by overflowing a local buffer allocated on the stack The target of the injected code is usually to launch a shell to the adversary Therefore the injected code is often referred to as shellcode 7

8 To understand how a buffer overflow attack works, we take a deeper look at the stack frame and its elements 8

9 Stack is a last in, first out (LIFO) memory area where the Stack Pointer (SP) points to the top word on the stack Usually, the stack grows downwards The stack can be accessed by two basic operations 1. Push elements onto the stack (SP is decremented) 2. Pop elements off the stack (SP is incremented) Stack is divided into individual stack frames Each function call sets up a new stack frame on top of the stack 1. Function arguments 2. Return address Upon function return (i.e., a return instruction is issued), control transfers to the code pointed to by the return address (i.e., control transfers back to the caller of the function) 3. Saved Base Pointer Base pointer of the calling function Variables/arguments are accessed via an offset to the base pointer 4. Local variables 9

10 Function call perfomed via the x86 CALL instruction E.g., CALL Function_A Stack SP Code <main>: CALL Function_A <Function_A>: 10

11 Function call perfomed via the x86 CALL instruction E.g., CALL Function_A The CALL instruction automatically pushes the return address on the stack, while the return address is simply the instruction preceding the call Stack Return Address Code <main>: CALL Function_A SP <Function_A>: 11

12 Function call perfomed via the x86 CALL instruction E.g., CALL Function_A The CALL instruction automatically pushes the return address on the stack, while the return address is simply the instruction preceding the call Function return is performed via the x86 instruction The instruction pops the return address off the stack and loads it into the instruction pointer (%EIP) Hence, the execution will continue in the main function Stack Return Address Code <main>: CALL Function_A <Function_A>: SP 12

13 The purpose of the function prologue is to backup selected registers, and to reserve space for local variables On Intel x86 (Notation: destination register is the first operand) Note: When the function is entered the stack pointer points to the return address of the function Store Save Base Pointer on the stack: push %ebp Initialize Base Pointer of the called function with the current value of the Stack Pointer: mov %ebp,%esp Reserve space for local variables (e.g.,12 Bytes): sub %esp,12 13

14 The purpose of the function epilogue is to set the Stack Pointer back to its original state, to restore selected registers, and to issue the return Reset the Stack Pointer (by loading it with %ebp): mov %esp, %ebp Restore the caller s Base Pointer: pop %ebp Pop the return address from the stack and return back to the caller: ret 14

15 Simple Echo program suffering from a stack overflow vulnerability The gets() function does not provide bounds checking 15

16 16

17 Stack Adversary Code <main>: CALL echo() CALL printf(), Program Memory 17

18 Adversary Stack Return Address SP Code <main>: CALL echo() CALL printf(), <echo>: CALL gets(buffer), Program Memory 18

19 Adversary Stack Return Address Saved Base Pointer Local Buffer Buffer[80] SP Code <main>: CALL echo() CALL printf(), <echo>: CALL gets(buffer), Program Memory 19

20 Stack Adversary Corrupt Control Structures NEW Return URN Address ADDR Saved PATTERN Base Pointer Local Buffer SHELLCODE Buffer[80] Code <main>: CALL echo() CALL printf(), SP <echo>: CALL gets(buffer), Program Memory 20

21 Adversary Stack NEW Return URN Address ADDR Saved PATTERN Base Pointer Local Buffer SHELLCODE Buffer[80] SP echo() now returns! Code <main>: CALL echo() CALL printf(), <echo>: CALL gets(buffer), Program Memory 21

22 Adversary Stack NEW Return URN Address ADDR Saved PATTERN Base Pointer Local Buffer SHELLCODE Buffer[80] SP Shellcode executes Code <main>: CALL echo() CALL printf(), <echo>: CALL gets(buffer), Program Memory 22

23 Why the attack is possible? The gets() function provides no bounds-checking C/C++ includes various functions providing no boundschecking, e.g., strcpy(): Copies a string into a buffer strcat(): Concatenates two strings scanf(): Read data from stdin (Standard Input) General defense against code injection attacks is W ^ X (Writable Xor Executable) With W ^ X memory pages can be either marked writable or executable Stack is marked writable Hence, the adversary can only inject his malicious code, but cannot execute it 23

24 24 24

25 25 25

26 Basic idea Instead of injecting code, use existing code Subvert the usual execution flow by redirecting it to functions in linked system libraries The process's image consists of 1. writable memory areas like stack and heap, 2. and executable memory areas such as the code segment and the linked system libraries The target for useful code can be found in the C library libc The C library libc Libc is linked to nearly every Unix program This library defines system calls and other basic facilities such as open(), malloc(), printf(), system(), execve(), etc. E.g., system ( /bin/sh ) 26

27 Libc provides the following useful functions to the adversary The system() function Executes a new program within a running program Example: system ("/bin/sh") This function executes the /bin/sh file (i.e., a new shell is launched) The execve() function Execute a new program and replace the (old) running program Example: execve (argv[0], argv, NULL); argv is a string array, where argv[0] = "/bin/sh" This function launches a new shell and replaces the running program 27

28 28

29 Stack Adversary Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Inject environment variable Environment Variables $SHELL = "/bin/sh" Program Memory 29

30 Stack Adversary Return Address SP Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 30

31 Stack Adversary Return Address Saved Base Pointer Local Buffer Buffer[80] SP Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 31

32 Adversary Corrupt Control Structures Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Stack Pointer to $SHELL Pointer to exit() Pointer Return to Address system() Saved PATTERN Base Pointer 2 Local Buffer PATTERN 1 Buffer[80] SP Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 32

33 Adversary Stack Pointer to $SHELL Pointer to exit() Pointer Return to Address system() Saved PATTERN Base Pointer 2 Local Buffer PATTERN 1 Buffer[80] SP echo() returns to system() Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 33

34 Adversary Stack Pointer to $SHELL Pointer to exit() Saved Pointer Return Base to Address system() Pointer Saved PATTERN Base Pointer 2 Local Buffer PATTERN 1 Buffer[80] SP Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 34

35 Adversary Stack Pointer to $SHELL Pointer to exit() Saved Pointer Return Base to Address system() Pointer Saved PATTERN Base Pointer 2 Local Buffer PATTERN 1 Buffer[80] SP system ( /bin/sh ) executing Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 35

36 Adversary Stack Pointer to $SHELL Pointer to exit() Saved Pointer Return Base to Address system() Pointer Saved PATTERN Base Pointer 2 Local Buffer PATTERN 1 Buffer[80] SP system ( /bin/sh ) returns to exit() Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 36

37 Adversary Stack Pointer to $SHELL Pointer to exit() Saved Pointer Return Base to Address system() Pointer Saved PATTERN Base Pointer 2 Local Buffer PATTERN 1 Buffer[80] SP Program terminates Program Code <main>: CALL echo() <echo>: CALL gets(buffer), Library Code <system>: <exit>: HALT Program Environment Variables $SHELL = "/bin/sh" Program Memory 37

38 Return-into-libc attacks bypass security mechanisms such as the W ^ X model, but suffer from the following restrictions The adversary relies on functions available in libc. Hence, the designers of libc could eliminate critical functions such as system(). The adversary can only invoke one function after the other. Hence, no branching is possible. 38