Defense against Code-injection, and Code-reuse Attack

Transcription

1 Operating Systems Security Defense against Code-injection, and Code-reuse Attack Computer Security & OS lab. Cho, Seong-je ( 조성제 ) sjcho at dankook.ac.kr Fall, 2018

2 Contents Buffer Overflows: Stack Smashing, Heap overflow, Global data overflow Background knowledge: Little endian vs. Big endian, Assembly language, Code-injection attacks & defenses Return-to-Shellcode Attack Code-reuse attacks: Return-to-Libc Attacks References & Source (Credit): Lecture: Code-reuse attacks and defenses, Lucas Davi, University of Duisbure-Essen Code-Reuse Attacks and Defenses, MSc. Lucas Vincenzo Davi, Technische Universitat Darmstadt Computer Security, Principles and Practice, 3 rd ed., William Stallings & Lawrie Brown EECS710: Information Security, Professor Hossein Saiedian, Fall 2014, Electrical Engineering and Computer Science, KU Return-Oriented Programming, David Brumley, CMU Introduction to Information Security, , Spring 2016, Control Hijacking, Avishar Wool, Tel Aviv University CAP6135: Malware and Software Vulnerability Analysis, Buffer Overflow I & II: Attack/Defense, Cliff Zou, Spring 2012/2014, UCF -2-

3 Learning Objectives Review Buffer overflows & Shellcode Understanding of Control hijacking attacks After studying this chapter, you should be able to: Describe how we can defend against code-injection attacks Define return-to-libc (Ret2Libc) attacks Describe what are the differences between basic BoF and Ret2Libc Hands-on experience on Ret2Libc Buffer overflow vulnerability lab with LoB -3-

4 Control Hijacking Attacks Control flow the order in which individual statements, instructions or function calls of an imperative program are executed or evaluated Control Hijacking Attacks (Runtime exploit) A control hijacking attack exploits a program error, particularly a memory corruption vulnerability, at application runtime to subvert the intended controlflow of a program. Control-hijacking attacks = Control-flow hijacking attacks Change of control flow Alter a code pointer (i.e., value that influences program counter) or, Gain control of the instruction pointer %eip Change memory region that should not be accessed E.g.) Code injection attacks, Code reuse attacks -4-

5 Control Flow Graphs (CFG) -5-

6 Control Hijacking Attacks Control Flow Graph (CFG) a representation, using graph notation, of all paths that might be traversed through a program during its execution Code injection attacks Adding a new node to the CFG Adversary can execute arbitrary malicious code Examples: Return to Shellcode (= Ret2Shellcode) Code-reuse attacks Adding a new path to the CFG Adversary is limited to the code nodes that are available in the CFG Examples: Ret2Libc ROP JOP (Jump-oriented programming) -6-

7 General Principle of Code Injection Attacks Source: Lecture: Code-Reuse Attacks and Defenses, Lucas Davi, Winter School on Binary Analysis,

8 General Principle of Code-Reuse Attacks -8-

9 Basic Execution -9-

10 Attacker s goal: Control Hijacking Attacks Take over target machine (e.g. Web server) Execute arbitrary code on target by hijacking the execution flow of a running program Common control hijacking methods Buffer overflows Integer overflows Heap overflows Format string vulnerability -10-

11 Buffer Overflow Buffer Overflow by NIST s Definition (NIST Glossary of Key Information Security Terms) A condition at an interface under which more input can be placed into a buffer or data holding area than the capacity allocated, overwriting other information. Attackers exploit such a condition to crash a system or to insert specially crafted code that allows them to gain control of the system. A buffer overflow occurs when data is written outside of the space allocated for the buffer. C does not check that writes are in-bound Buffer overflow = Buffer overrun Where can a buffer be located? -11-

12 cdecl the default for Linux & gcc -12-

13 Buffer Overflows Stack-based attacks (stack smashing) = stack overflows Heap-based attacks More advanced Very dependent on system and library version Return-to-libc (Ret2Libc) Return-into-libc Return-Oriented Programming (ROP) -13-

14 Brief History of Buffer Overflow Attacks Buffer overflow is a very common attack mechanism from 1988 Morris Worm to Code Red, Slammer, Sasser and many others -14-

15 Buffer Overflow & Programming Language Buffer Overflow: A Well-Known Problem A very common attack mechanism Prevention techniques known Still of major concern due to legacy of buggy code in widely deployed OSes and applications continued careless programming practices by programmers A Little Programming Language History At machine level, all data are stored in an array of bytes interpretation depends on instructions used Modern high-level languages have a strong notion of type and valid operations not vulnerable to buffer overflows does incur overhead, some limits on use C and related languages have high-level control structures, but allow direct access to memory hence are vulnerable to buffer overflow have a large legacy of widely used, unsafe, and hence vulnerable code -15-

16 Buffer Overflow Basics Mostly relevant for C/C++ programs Caused by programming error Allows more data to be stored than capacity available in a fixed sized buffer buffer can be on stack, heap, global data Overwriting adjacent memory locations Consequences: corruption of program data unexpected transfer of control memory access violation execution of code chosen by attacker -16-

17 Buffer Overflow Attacks To exploit a buffer overflow an attacker needs: must identify a buffer overflow vulnerability in some program Identifying vulnerable programs can be done by: Inspection of program source tracing the execution of programs as they process oversized input Using tools such as fuzzing to automatically identify potentially vulnerable programs understand how buffer is stored in memory and determine potential for corruption Stack Buffer Overflow Occurs when buffer is located on stack used by Morris Worm Smashing the Stack paper popularized it Have local variables below saved frame pointer and return address hence overflow of a local buffer can potentially overwrite these key control items Attacker overwrites return address with address of desired code program, system library or loaded in buffer -17-

18 Vulnerable APIs and Target programs in Buffer Overflows Table 10.2 Some Common Unsafe C Standard Library Routines Some Common Unsafe C Standard Library Routines gets(char *str) sprintf(char *str, char *format,...) strcat(char *dest, char *src) strcpy(char *dest, char *src) vsprintf(char *str, char *fmt, va_list ap) read line from standard input into str create str according to supplied format and variables append contents of string src to string dest copy contents of string src to string dest create str according to supplied format and variables strcpy() strncpy() strlcpy() In Buffer overflow attacks, Target program can be: A trusted system utility Network service daemon Commonly used library code, which handles common document formats (e.g., the library routines used to decode and display GIF or JPEG images) The input is not from a terminal or network connection, but from the file being decoded and displayed -18-

19 Buffer Overflows: Code-injection Attacks Code-injection Attacks a subclass of control hijacking attacks that subverts the intended controlflow of a program to previously injected malicious code Shellcode code supplied by attacker often saved in buffer being overflowed traditionally transferred control to a shell (user command-line interpreter) machine code specific to processor and OS traditionally needed good assembly language skills to create more recently have automated sites/tools -19-

20 Code-injection Attacks An example of malicious code is shellcode One of Control-Flow Attacks -20-

21 Unix Shellcode In Windows terms: command.exe -21-

22 Big-endian vs. Little-endian Big-endian (POWER family): Linux on SPARC, PowerPC, and z/architecture, Mac OS X on Power PC Little-endian (x86 family): Linux/Windows on x86, x64, and Itanium -22-

23 Linux strings command -23-

24 x86 Assembly language on AT&T vs. Intel AT&T syntax, which is the default for objdump, uses <src>, <dst> Mnemonic Meaning mov ebx, eax Move contents of ebx into eax add ebx, eax Calculate eax = eax + ebx shl $2, ecx Calculate ecx = ecx << 2 Intel syntax, which uses <dst>, <src> Mnemonic Meaning mov eax, ebx Move contents of ebx into eax add eax, ebx Calculate eax = eax + ebx shl ecx, 2 Calculate ecx = ecx << 2-24-

25 Advantages very effective Buffer Overflows attack code runs with privileges of exploited process can be exploited locally and remotely interesting for network services Disadvantages architecture dependent directly inject assembler code operating system dependent use call system functions some guesswork involved (correct addresses) -25-

26 Overflow Types Overflow memory region on the stack overflow function return address overflow function frame (base) pointer overflow longjump buffer Overflow (dynamically allocated) memory region on the heap Overflow function pointers stack, heap, BSS -26-

27 Other Overflow Attacks (Other Forms of Overflow Attacks) Heap overflow Global Data overflow -27-

28 Programs and Processes Figure 10.4 Program Loading into Process Memory -28-

29 Attack buffer located in heap Heap Overflow typically located above program code memory is requested by programs to use in dynamic data structures (such as linked lists of records) No return address hence no easy transfer of control may have function pointer, buffer, and vulnerable function gets() or manipulate management data structures Defenses Move function pointers Q) Which has higher address of inp and process variables on next slide? Making the heap non-executable -29-

30 Heap Overflow Example Target address could be 0x080497b8 (with bytes reversed because x86 is littleendian) -30-

31 Global Data Overflow can attack buffer located in global data may be located above program code if has function pointer and vulnerable buffer & function or adjacent process management tables aim to overwrite function pointer later called Defenses Move function pointers arranging function pointers to be located below any other types of data Making global data region non-executable -31-

32 Global Data Overflow Example The global structure was found to be at address 0x , which was used as the target address in the attack. -32-

33 Defense against Code-injection Attacks Data Execution Prevention -33-

34 Buffer Overflow Defenses Buffer overflows are widely exploited Large amount of vulnerable code in use despite cause and countermeasures known Two broad defense approaches compile-time - harden new programs run-time - handle attacks on existing programs Control hijacking: Platform defenses Hardware + Operating system -34-

35 Non Executable Address Space (Run-time defense) Many BO attacks copy machine code into buffer and transfer control to it Use virtual memory support to make some regions of memory nonexecutable (to avoid exec of attacker s code) e.g. stack, heap, global data need H/W support in MMU long existed on SPARC/Solaris systems recent on x86 Linux/Unix/Windows systems The adversary can only inject his malicious code, but cannot execute it Issues: support for executable stack code Some apps need executable stack (e.g. LISP interpreters) Special provisions are needed -35-

36 Marking memory as non-execute (W X) Prevent attack code execution by marking stack, heap, data as non-executable. (von Neumann architecture Harvard-based computing architecture) Harvard architecture: code and data are strictly separated from each other AMD: NX-bit ( No Execute, from AMD Athlon 64) Intel: XD-bit ( Executable Disable, from Intel P4 Prescott) NX bit in every Page Table Entry (PTE) Modern OSes enable W X by default (Windows, Linux, ios, Android): Linux (via PaX project); OpenBSD Windows: since XP SP2 ( DEP (Data Execution Prevention)) Boot.ini : /noexecute=optin or AlwaysOn Visual Studio: /NXCompat[:NO] Limitations: Some apps need executable heap (e.g. JITs). Does not defend against `return-to-libc exploits -36-

37 Data Execution Prevention (DEP) Prevent execution from a writable memory (data) area -37-

38 Examples: DEP control in Windows 7 Computer > right-click Properties > Advanced system settings > Performance (Settings) > Data Execution Prevention DEP terminating a program -38-

39 Code-Reuse Attacks (An Overflow Variant) Return to Libc (Ret2Libc) attacks Return-Oriented Programming attacks -39-

40 Code-Reuse Attacks Where are normally executable codes located? -40-

41 Return-to-Libc attacks Basic idea of return-to-libc attacks Overwrite RET addr with addr of libc function Use existing code instead of injecting code (No injected 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, data 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 library libc Libc is linked to nearly every Unix/Linux program This library defines system calls and other basic facilities such as open(), malloc(), printf(), system(), execve(), etc. E.g., system ( /bin/sh") -41-

42 Useful Functions in Libc 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 le (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, whereas argv[0] = /bin/sh" This function launches a new shell and replaces the running program -42-

43 Return to Libc Attack Control hijacking without code injection Code-Reuse Attack: a subclass of control-flow attacks that subverts the intended control-flow of a program to invoke an unintended execution path inside the original program code. -43-

44 Adversary transmits malicious input Return-to-Libc (1) -44-

45 Return-to-Libc (2) Input contains pattern bytes, a new ret_addr pointing to system(), -45-

46 Return-to-Libc (3), and a pointer to the /bin/sh string -46-

47 Return-to-Libc (4) When echo() returns, system() launches a new shell -47-

48 Return-to-libc (1/2) Using existing code (e.g.,: libc function) instead of injecting code E.g.) system( /bin/sh ); execve (argv[0], argv, NULL); 0x400fbff9 #include <stdio.h> void echo ( ) { char buffer[80]; gets (buffer); puts (buffer); } int main ( ) { echo ( ); printf ( "Done" ); return 0; } 0x40058ae0 Exploit 예 A *80 + B *4 + \xe0\x8a\x05\x40 + AAAA + \xf9\xbf\x0f\x40-48-

49 Return-to-libc (2/2) When echo() returns, system() launches a new shell Bypass W X model -49-

50 Return to Libc Attack Basic idea is that most c programs will be compiled with libc and thus you ll have access to these functions (like printf, gets, system, exit, etc) Even though stack/heap is nx, libc programs loaded in memory can be used Using ret2libc One interesting thing that ret2libc can do is to actually execute a shell payload would look like this: junk to overwrite ebp+address to system() + 4bytes junk or address to exit() + address to /bin/ sh of course /bin/sh has to be loaded in memory somewhere Execute a shell Note: there are multiple ways to do this for purposes of shell popping, you can use an environmental variable to load /bin/sh and search for it. A helpful command to search for environmental variable address in gdb is x/32s *environ -50-

51 Ret2Libc What if we don t know the absolute address any pointers to /bin/sh (objdump gives addresses, but we don t know ASLR constants) ptr to argv /bin/sh argc return addr &system caller s ebp %ebp Return to Libc Generalization: can generate arbitrary programs using return oriented programming (ROP) buf (64 bytes) argv[1] buf %esp -51-

52 Return-to-Libc (Ret2Libc) Attack stack overflow variant replaces return address with standard library function response to non-executable stack defences attacker constructs suitable parameters on stack above return address function returns and library function executes e.g. system( shell commands ) attacker may need exact buffer address can even chain two library calls Scorecard for ret2libc No injected code DEP ineffective Requires knowing address of system... or does it. -52-

53 Countermeasures for Ret2Libc What if we don t know the address of system()? What if system() is removed from libc.so? Remove security-sensitive functions from shared libraries? This might break legitimate uses Address Space Layout Randomization (ASLR) Control-Flow Integrity (CFI) -53-

54 Basics of Memory Randomization ASLR randomizes the base address of code/data segments -54-

55 ASLR Example Booting twice loads libraries into different locations: -55-

56 Defense against return to libc : randomization ASLR: (Address Space Layout Randomization) Map shared libraries to random location in process memory Attacker cannot jump directly to exec function Deployment on 32-bit OS: Windows Vista: 8 bits of randomness for DLLs aligned to 64K page in a 16MB region 256 choices Linux (via PaX): 16 bits of randomness for libraries More effective on 64-bit architectures Other randomization methods: System-call randomization: randomize system-call IDs Instruction Set Randomization (ISR) Generally: Software Diversity -56-

57 Control-Flow Integrity (CFI) Defense against code injection & code-reuse attacks -57-

58 CFI CFI indirect jump check -58-

59 Summary of Buffer Overflows Buffer Overflow Attacks = One of Control Hijacking Attacks -59-

60 Code injection attacks Code-reuse attacks Control Hijacking Attacks -60-

61 Control Hijacking Attacks & Defenses Control hijacking attacks = Control flow hijacking attacks Attacker s goal: Take over target machine (e.g. web server) Execute arbitrary code on target by hijacking application control flow Examples: Buffer overflow, Integer overflows, Format string attacks Control Hijacking Attacks Code injection Injected code, shellcode Code-reuse attacks Existing code, Ret2Libc, Return Oriented Programming (ROP), Protection Writable xor executable (W X), DEP ASLR Control Flow Integrity -61-

62 Buffer Overflows and Defenses Buffer overflows are one of Control hijacking attacks Stack buffer overflows targeted buffer is located on the stack shellcode shellcode development position independent cannot contain NULL values heap overflows global data area overflows A defence against Buffer overflow NX, DEP, W X ASLR, CFI -62-