CSCD27 Computer and Network Security Code Security: Buffer Overflows 13 Buffer Overflow CSCD27 Computer and Network Security 1 Buffer Overflows Extremely common bug. First major exploit: 1988 Internet Worm. Used fingerd 15 years later: 50% of all CERT advisories: 1998: 9 out of 13 2001: 14 out of 37 2003: 13 out of 28 Still a top-10 exploit in 2015, estimated at 20% Can give attacker complete control of victim host Developing buffer overflow attacks: identify buffer overflow within an application design an exploit 13 Buffer Overflow CSCD27 Computer and Network Security 2 Buffer Overflows are everywhere /default.ida?nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u 9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00 c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a Code Red worm URL signature Web servers (Heartbleed), SQL servers, code repo s, network services such as sendmail, ftp, telnet, xterm, httpd, named,... Hardware such as network switches can be hung/crashed by similar methods Most common exploited code-flaw in reported attacks Required attacker coding practices: planted attack program must not contain the \0 char o since null byte will terminate copy operation prematurely overflow should not crash program before attack function exits 13 Buffer Overflow CSCD27 Computer and Network Security 3 CSCD27F Computer and Network Security 1
So You Want to be a Hacker? You ll need to: understand C functions and the runtime be somewhat familiar with machine code know how systems calls are performed understand the exec() system call Also need to know which CPU and OS are running on the target machine. Why? Details vary between CPU s and OS s: o little endian vs. big endian (e.g. x86 vs. Motorola) o -frame ucture (Linux vs. Windows) o direction of growth 13 Buffer Overflow CSCD27 Computer and Network Security 4 What are Buffer Overflows? Suppose you are writing a C program that requires some input from the user: First of all, what is the code supposed to do? gets() reads as many bytes of input as are available on standard input, storing them in array buffer[] Simple enough piece of code. But now consider the unexpected... if the input happens to contain more than 80 bytes of data, then what? 13 Buffer Overflow CSCD27 Computer and Network Security 5 What are Buffer Overflows? gets() will dutifully keep writing bytes, right past the end of our buffer array, with what consequence? some other part of memory will get overwritten by this input This is a bug, not that hard to spot, but also not that hard to introduce, if you've got your mind on something else, and you haven't been bitten by this one before once you learn the pattern you become sensitized to it and are less likely to miss it in future code So what happens when we blow past the end of buffer writing bytes? 13 Buffer Overflow CSCD27 Computer and Network Security 6 CSCD27F Computer and Network Security 2
What are Buffer Overflows? what happens when we blow past the end of buffer writing bytes? Typically the program crashes leaving a "core-dump", often recorded as file "core" Of course you don't necessarily catch this in your testing, so maybe a user of your application gets a weird abort at runtime bad, especially if the crashed program is a server that should be always on maliciously causing a service to stop responding: DoS! What may be less obvious is that the consequences can be even worse 13 Buffer Overflow CSCD27 Computer and Network Security 7 More Buffer Overflows Let's make a slight adjustment to the example to show one possible consequence: int authenticated = 0; Alogin function (not shown) sets the authenticated flag, only if the user logs in with a valid password Unfortunately, the authenticated flag is stored in memory right after array buffer[] 13 Buffer Overflow CSCD27 Computer and Network Security 8 More Buffer Overflows int authenticated = 0; If the attacker can write 81 bytes of data to buffer, with the 81st byte set to a non-zero value, this will set the authenticated flag to true, and the attacker will have the status of an authenticated user! The program above allows that to happen, because gets() does no bounds-checking: it will write as much data to buffer as is supplied to it In other words, the code above is vulnerable: an attacker who can control the input to the program, can bypass the password-authentication check 13 Buffer Overflow CSCD27 Computer and Network Security 9 CSCD27F Computer and Network Security 3
Code Injection Attack Here's another variation, that poses a different kind of threat: int (*func_ptr)(); What is *func_ptr? A pointer to... a function, e.g. a callback, for event-handlers. The function referenced by *func_ptr is invoked elsewhere in the program This enables a more serious attack. Do you see it? If an attacker can overwrite func_ptr with an address of his choice, he will be able to redirect program execution to some chosen memory location 13 Buffer Overflow CSCD27 Computer and Network Security 10 Code Injection Attack int (*func_ptr)(); An attacker could supply inputconsisting of malicious inuctions, followed by a few bytes that overwrite func_ptr with some address A When func_ptr is next invoked, the flow of control is redirected to address A attacker can choose address A however he likes; e.g. &buffer[0] This attack is referred to as a malicious code-injection attack Many variations on this attack are possible; malicious code need not be stored in buffer[]; can be elsewhere in memory 13 Buffer Overflow CSCD27 Computer and Network Security 11 Stack Based Buffer Overflows Stack-based buffer overflows are more common than other forms; they exploit the runtime layout of memory (next slide) When function is called, parameters/local variables stored on a (pushed at call time, popped at urn time), together with a pointer to the caller's frame (for the pop) and a urn address, where execution resumes upon urn Revisiting our insecure()definition in this context, add a parameter so we can see where it ends up on the and change from gets() to cpy(): void insecure(char *) { cpy(buffer, ); 13 Buffer Overflow CSCD27 Computer and Network Security 12 CSCD27F Computer and Network Security 4
Linux process address space %esp ( ptr) User Stack 0xC0000000 brk (heap ptr) Shared libraries Run time heap 0x40000000 Loaded from exec Code (text) Unused 0x08048000 13 Buffer Overflow CSCD27 Computer and Network Security 13 0 Stack Frame Layout Caller s frame SP Parameters Return address Stack Frame Pointer Callee saved registers Local variables higher address Stack growth as functions are called lower address 13 Buffer Overflow CSCD27 Computer and Network Security 14 Stack Buffer Overflows void insecure(char *) { Notice how buffer has moved inside the function to become a local variable... so that it will be allocated on the In a " smashing" attack, a buffer overflow causes the saved SP and urn address to be overwritten In the simplest form of -smashing attack, malicious code is introduced somewhere in the program's address space, possibly within the buffer array itself If an 88-byte input is provided as the value of to the cpy() call, the last 8 bytes will overwrite the saved frame pointer and urn addr(assuming a 32-bit processor), the latter of which is set to point at the malicious code! 13 Buffer Overflow CSCD27 Computer and Network Security 15 cpy(buffer, ); CSCD27F Computer and Network Security 5
Stack Buffer Overflows Suppose a system command contains the function: void insecure(char *) { cpy(buffer, );... When insecure() is invoked, looks like this: top of buffer Local variables addr Stack grows this way 13 Buffer Overflow CSCD27 Computer and Network Security 16 Pointer to Execute Arguments previous code at frame this address after func() finishes frame of calling function Stack Buffer Overflows What happens if the caller supplies 88 bytes (or more) of input, not 80 bytes as insecure() intended? After cpy()the will look like this: Top of buffer addr Stack grows this way frame of calling function cpy() fills buffer bytes this way the value stored in this location will be interped as urn address for caller of insecure() so what will our wily attacker use as the value of param? 13 Buffer Overflow CSCD27 Computer and Network Security 17 Stack Smashing Exploit Attacker puts code into buffer such that after cpy() looks like this: Top of attack code addr frame of calling function attacker code e.g.: execv(/bin/sh) expressed in ASM and run as, say root? When insecure() exits, user gets root shell!! note: attack code runs in the exploited flaw: no range checking in cpy() challenge for attacker: to determine addr attacker must correctly guess memory position of frame when insecure() is called 13 Buffer Overflow CSCD27 Computer and Network Security 18 CSCD27F Computer and Network Security 6
Stack Smashing Exploit How can attacker mitigate not knowing actual runtime address of attack code? Top of NOP slide attack code addr frame of calling function Attacker guesses approximate memory position of frame when insecure() is called Inserts NOP (no-op) slide in front of attack code NOP code has no effect, but executes sequentially until inuction pointer gets to attack-code 13 Buffer Overflow CSCD27 Computer and Network Security 19. 13 Buffer Overflow CSCD27 Computer and Network Security 20 13 Buffer Overflow CSCD27 Computer and Network Security 21 CSCD27F Computer and Network Security 7
Format Strings in C Proper use of printf format ing: int test = 1234; printf("test = %d in decimal, %X in hex", test, test); o Prints: test = 1234 in decimal, 4D2 in hex Careless use of printf format ing: char buffer[13]="hello, world!"; printf(buffer); // should use printf("%s", buffer); o If buffer contains format symbols starting with %, location pointed to by printf sinternal pointer will be interped as an argument of printf. This can be exploited to move printf sinternal pointer 13 Buffer Overflow CSCD27 Computer and Network Security 22 Format String Attack if (fgets(buffer,sizeof buffer,stdin)==null) urn; printf(buffer); What is the if-statement testing? Why does it urn? fgets() reads into buffer until sizeof-buffer- bytes have been read, and ing value in buffer is then terminated with a null byte. fgets() urns NULL if EOF (end-of-file) is encountered. What happens when the printf() is executed if its argument contains a % formatting character? If there is a %, then printf() will look for arguments, which probably don't exist, and that in turn may cause the program to crash. Hmm, same way we got started above, with a crash, which is bad news, but could it actually be worse? 13 Buffer Overflow CSCD27 Computer and Network Security 23 Format String Attack if (fgets(buffer,sizeof buffer,stdin)==null) urn; printf(buffer); Let's try it out... see insecure.c in buf_ovfl_ex (on Lectures page), compile and run a.out < stdinn stdin0 (no format ing in input) -ok stdin1 (contains %s) core dump, awww, but wait, this is a DoS attack!! If the stdinvalue is "%x:%x", then the 1st 2 words of memory will be printed. stdin2 (%x:%x) -this is cool stdin3 (%x:%x:%x:%x:%x %s) -shows ing stored at memory address given by 6th word of, interped as address Different results depending on whether you compile and run on mathlab or other Linux system. Why? 13 Buffer Overflow CSCD27 Computer and Network Security 24 CSCD27F Computer and Network Security 8
Format String Attacks Lots of variations on these ideas, permit an attacker to peer into the victim's addr space, e.g.: If attacker can observe output of function within Web server, and that output shows up in the browser window things start to get interesting a remote attacker can poke around the address space on your server. Why should you care? if (fgets(buffer,sizeof buffer,stdin)==null) urn; printf(buffer); consider what may be stored in the server s memory at runtime: passwords, crypto keys, other confidential info. Even worse, the attacker can write any value to ANY address in the victim's address space, using %n 13 Buffer Overflow CSCD27 Computer and Network Security 25 Preventing Buffer Overflow Attacks Main problem: cpy(), cat(), sprintf(), gets(), scanf() perform no range checking Safe versions ncpy(), ncat() misleading: Defenses: o ncpy() may leave buffer unterminated o ncpy(), ncat() encourage off-by-1 bugs Type-safe languages (Java, ML). Legacy code? Mark as non-execute. Randomize location. Static Analysis Run time checking: StackGuard, Libsafe, SafeC, (Purify) 13 Buffer Overflow CSCD27 Computer and Network Security 29 Preventing Overflow Attacks Some programming languages are designed to be intrinsically memory-safe, no matter what the programmer does Java for example Memory-safe languages eliminate the opportunityfor a common kind of programming mistake that has been known to cause serious security vulnerabilities What if you re stuck maintaining a legacy app written in a non-safe language, like C or C++, which relies on the programmer to preserve memory safety? 13 Buffer Overflow CSCD27 Computer and Network Security 30 CSCD27F Computer and Network Security 9
Mark Stack as Non-Execute Basic -smashing exploit can be prevented by marking segment as non-executable NX-bit on AMD Athlon 64, XD-bit on Intel P4 Prescott, but not 32-bit x86 (NX bit in every Page Table Entry (PTE)) Support in Win XP SP2+, Win 7/8/10. Code patches for Linux Limitations: Doesn t defend against `urn-to-libc exploit o overflow sets -addr to address of libc function Doesn t block more general overflow exploits: o overflow on heap: overflow buffer next to func pointer Doesn t prevent logic-modification errors such as overflow into authentication flag Some apps need executable (e.g. LISP interpers) 13 Buffer Overflow CSCD27 Computer and Network Security 31 Runtime Checking: StackGuard Many many run-time checking techniques Here, only cover methods relevant to overflow protection Solutions 1: StackGuard (WireX) Run time tests for integrity. Embed canaries in frames and verify their integrity prior to function urn. top of local Frame 2 canary local Frame 1 canary growth 13 Buffer Overflow CSCD27 Computer and Network Security 33 Stackguard Canary Types Random canary: choose random ing at program startup insert canary ing into every frame verify canary before urning from function to avoid corrupting random canary, attacker must learn current random ing (hard) Terminator canary: canary = "\0", newline, linefeed, EOF ing functions like cpy(), gets() will not copy beyond terminator canary hence, attacker cannot use ing functions to corrupt 13 Buffer Overflow CSCD27 Computer and Network Security 34 CSCD27F Computer and Network Security 10
StackGuard Implementation StackGuard implemented as a GCC patch program must be recompiled Modest performance hit: e.g. 8% for Apache Web server Newer version: PointGuard protects function pointers and setjmpbuffers by placing canaries next to them more noticeable performance effects Note: canaries don t offer complete protection some -smashing attacks leave canaries untouched 13 Buffer Overflow CSCD27 Computer and Network Security 35 Run time checking: Libsafe Solution 2: libsafe (Avaya Labs) top of dynamically loaded library (if can t recompile) intercepts calls to e.g. cpy(buf,src) o validates sufficient space in current frame: frame-pointer buf > len(src) o if so, executes cpyotherwise, terminates application cpy() fills dest bytes this way -addr src buf -addr libsafe cpy main 13 Buffer Overflow CSCD27 Computer and Network Security 36 Buffer Overflows Buffer overflows remain an important mechanism for system compromise e.g. Code Red 2 worm infected over 250K machines; utilized a buffer overflow in IIS Attackers have been very resourceful in working around apparent showstoppers, such as: the buffer variable being stored in the heap malicious code's location is unknown (e.g. randomization) buffer characters limited to lower-case letters /default.ida?nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u 9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00 c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a Code Red worm URL signature things that would seem to make attack infeasible -not so! 13 Buffer Overflow CSCD27 Computer and Network Security 37 CSCD27F Computer and Network Security 11