CS 290 Host-based Security and Malware Christopher Kruegel [email protected] Overflows3!Buffer Overflows • Result from mistakes done while writing code – coding flaws because of • unfamiliarity with language • ignorance about security issues • unwillingness to take extra effort • Often related to particular programming language • Buffer overflows – mostly relevant for C / C++ programs – not in languages with automatic memory management – these use • dynamic bounds checks (e.g., Java) • automatic resizing of buffers (e.g., Perl)4!Buffer Overflows • Goal – change flow of control (flow of execution), and – execute arbitrary code • Requirements 1. inject attack code or attack parameters 2. abuse vulnerability and modify memory such that control flow is redirected • Change of control flow – alter a code pointer (i.e., value that influences program counter) – change memory region that should not be accessed5!Buffer Overflows • One of the most used attack techniques • Advantages – very effective • 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 guess work involved (correct addresses)6!Buffer Overflows • Process memory regions – Stack segment • local variables • procedure calls – Data segment • global initialized variables (data) • global uninitialized variables (bss) • dynamic variables (heap) – Code (Text) segment • program instructions • usually read-only • Display with cat /proc/<pid>/maps Stack Heap Code Top of Memory BSS Data7!Buffer Overflows • Overflow memory region on the stack – overflow function return address • Phrack 49 -- Aleph One: Smashing the Stack for Fun and Profit • Phrack 58 -- Nergel: The advanced return-into-lib(c) exploits – overflow function frame (base) pointer • Phrack 55 -- klog: The Frame Pointer Overflow – overflow longjump buffer • Overflow (dynamically allocated) memory region on the heap – Phrack 57 -- MaXX: Vudo malloc tricks -- anonymous: Once upon a free() ... • Overflow function pointers – stack, heap, BSS (e.g., PLT)8!Stack • Usually grows towards smaller memory addresses – Intel, Motorola, SPARC, MIPS • Processor register points to top of stack – stack pointer – SP – points to last stack element or first free slot • Composed of frames – pushed on top of stack as consequence of function calls – address of current frame stored in processor register • frame/base pointer – FP – used to conveniently reference local variables9!Stack previous frame function arguments return address previous frame pointer local variables stack pointer frame pointer current frame caller code 1. push arguments 2. call instruction callee code 1. push frame pointer 2. move stack pointer to frame pointer 3. increase stack pointer10 Procedure Call 5 Saved IP Saved EBP 3 411 A Closer Look (gdb) disas main Dump of assembler code for function main: 0x0804836d <main+0>: push %ebp 0x0804836e <main+1>: mov %esp,%ebp 0x08048370 <main+3>: sub $0x18,%esp 0x08048373 <main+6>: and $0xfffffff0,%esp 0x08048376 <main+9>: mov $0x0,%eax 0x0804837b <main+14>: add $0xf,%eax 0x0804837e <main+17>: add $0xf,%eax 0x08048381 <main+20>: shr $0x4,%eax 0x08048384 <main+23>: shl $0x4,%eax 0x08048387 <main+26>: sub %eax,%esp 0x08048389 <main+28>: movl $0x0,0xfffffffc(%ebp)󳆒 0x08048390 <main+35>: movl $0x5,0x4(%esp)󳆒 0x08048398 <main+43>: movl $0x4,(%esp)󳆒 0x0804839f <main+50>: call 0x8048354 <foo> 0x080483a4 <main+55>: mov %eax,0xfffffffc(%ebp)󳆒 5 4 0x080483a412 A Closer Look (gdb) breakpoint foo Breakpoint 1 at 0x804835a (gdb) run Starting program: ./test1 Breakpoint 1, 0x0804835a in foo ()󳆒 (gdb) disas Dump of assembler code for function foo: 0x08048354 <foo+0>: push %ebp 0x08048355 <foo+1>: mov %esp,%ebp 0x08048357 <foo+3>: sub $0x10,%esp 0x0804835a <foo+6>: movl $0x3,0xfffffffc(%ebp)󳆒 0x08048361 <foo+13>: mov 0xc(%ebp),%eax 0x08048364 <foo+16>: add 0x8(%ebp),%eax 0x08048367 <foo+19>: imul 0xfffffffc(%ebp),%eax 0x0804836b <foo+23>: leave 0x0804836c <foo+24>: ret End of assembler dump. (gdb)󳆒 5 4 0x080483a4 0xafdde9f8 313 The foo Frame (gdb) stepi 0x08048361 in foo ()󳆒 (gdb) x/12wx $ebp-16 0xaf9d3cc8: 0xaf9d3cd8 0x080482de 0xa7faf360 0x00000003 0xaf9d3cd8: 0xafdde9f8 0x080483a4 0x00000004 0x00000005 0xaf9d3ce8: 0xaf9d3d08 0x080483df 0xa7fadff4 0x08048430 5 4 0x080483a4 0xafdde9f8 3!Taking Control of the Program15!Buffer Overflow • Code (or parameters) get injected because – program accepts more input than there is space allocated • In particular, an array (or buffer) has not enough space – especially easy with C strings (character arrays) – plenty of vulnerable library functions strcpy, strcat, gets, fgets, sprintf .. • Input spills to adjacent regions and modifies – code pointer or application data • all the possibilities that we have enumerated before – normally, this just crashes the program (e.g., sigsegv)16 Example // Test2.c #include <stdio.h> #include <string.h> int vulnerable(char* param)! { char buffer[100]; strcpy(buffer, param); } int main(int argc, char* argv[]) { vulnerable(argv[1]); printf(“Everything's fine\n”); } Buffer that can contain 100 bytes Copy an arbitrary number of characters from param to buffer17 Let's Crash > ./test2 hello Everything's fine > ./test2 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Segmentation fault >18 What Happened? buffer 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 > gdb ./test2 (gdb) run hello Starting program: ./test2 Everything's fine (gdb) run AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA