On the Effectiveness of Address-Space Randomization CS6V Brian Ricks and Vasundhara Chimmad

Overview ● ASLR: Address Space Layout Randomization – Certain brute force attacks can be thwarted by constantly randomizing the address-space layout each time the program is restarted. – The attacker must either craft a specific exploit for each instance of a randomized program or perform brute force attacks to guess the address-space layout.

Overview – PaX ASLR ● PaX applies ASLR to binaries and dynamic libraries. – For the purposes of ASLR, a process’s user address space consists of three areas, called the executable, mapped, and stack areas. – ASLR randomizes these three areas separately, adding to the base address of each one an o ff set variable randomly chosen when the process is created. ● We will focus on the mapped area, which includes the heap and dynamic libraries

Overview – PaX ASLR ● PaX ASLR provides the following randomness: – 16 bits for addresses in the executable area – 16 bits for addresses in the mapped area – 24 bits for addresses in the stack area ● We will focus on the mapped data offset, which we call delta_mmap – Limited to 16 bits of randomness: ● Altering bits would affect the mmap() function in terms of handling large memory mappings ● Altering bits 0-11 would cause memory mapped pages not to be aligned on page boundaries

Breaking PaX ASLR ● Overview – Target: the Apache web server ● No known buffer overflows, so one will be replicated in the Apache source – Exploit using return-to-libc technique ● The stack addresses are randomized using 24-bits – Makes guessing them by brute-force not feasible ● Instead, we use knowledge of the stack layout, as the layout does not change.

Breaking PaX ASLR ● Overview – Determine the value of delta_mmap ● Brute force attack that pinpoints an address in libc – Once delta_mmap is obtained, mount a return-to-libc attack to spawn a shell ● We assume that the stack is write only, in that we cannot execute shellcode directly on the stack ● We instead call a predefined function from the libc library, which is linked by default. – One such function, system(), can execute programs, such as a shell.

Precomputing libc Addresses ● In the libc library, determine the address o ff sets of the functions system(), usleep(), and a return (ret) instruction. – We can obtain these offsets by using the standard objdump tool, which displays information from object files (such as the libc library).

Precomputing libc Addresses ● Once these offsets are obtained, we can calculate the correct virtual addresses of system() and ret as follows: address = 0x o ff set + delta_mmap. – 0x : This is the standard base address for memory obtained using the mmap() function ● Already known – o ff set: The offset from the standard base address ● Obtained from objdump – delta_mmap: The PaX ASLR offset ● We need to figure this out!!

Obtaining the value of delta_mmap ● Obtain the value of delta_mmap ● What about usleep()? – We use this function to help us determine delta_mmap. – delta_mmap comprises the 'missing' 16-bits in the address for usleep() (we already know the others: they comprise the base address and the offset) – We try to guess the address for usleep() by guessing the value of delta_mmap: ● Only 2^16 = possible values ● Possible by brute force

Obtaining the value of delta_mmap ● Why usleep()? – Gives deterministic behavior in Apache for a successful guess vs a failed guess ● Failed guess: child process crashes, Apache spawns a new process (forks) – Connection closes immediately – The new child process uses the same delta_mmap value as the crashed one! – Can keep guessing, knowing that delta_mmap will not change ● Successful guess: child process hangs for 16 seconds – We can infer from this 16 second delay that we found the correct address for usleep() – The guess for delta_mmap is the correct value

● How do we do this? – Iterate over all possible values for delta_mmap starting from 0 and ending at – For each value of delta_mmap, compute the guess for the randomized virtual address of usleep() from its o ff set and base address. – Create the attack bu ff er and send it to the Apache web server (buffer overflow exploit). – If the connection closes immediately, continue with the next value of delta_mmap. If the connection hangs for 16 seconds, then the current guess for delta_mmap is correct. Obtaining the value of delta_mmap

● Why does the child process hang for 16 seconds on a successful guess? – We send to usleep() an argument of 16,843,009, which corresponds to roughly 16 seconds that the process will sleep for. – This value is represented in the attack buffer as 0x ● Notice that if we want a number any lower than this, we will end up with a '00' somewhere in the hex representation. ● A '00' will be interpreted by strcpy() as a null terminator, and thus will terminate before overflowing the entire buffer. Obtaining the value of delta_mmap

● What does the attack buffer look like? – Top figure: the stack before probing – Bottom figure: the stack after one probe ● The buffer is toward the bottom in the figure, and the overflow spreads upward, as denoted by the arrow Obtaining the value of delta_mmap

● Iteration of one probe – Enter ap_getline() ● This function is modified to include a 64 char buffer (which the attack buffer is written to) and the strcpy() function which will cause the overflow – The return address (EIP) in the stack frame is overwritten with the guessed address for usleep() ● When ap_getline() returns, control is redirected to the guessed address – The stack pointer (EBP) is overwritten with 0xDEADBEEF (must be overwritten to reach EIP) Obtaining the value of delta_mmap

● Iteration of one probe ● When ap_getline() returns: – If the guess is correct, the address 0xDEADBEEF (above EIP) will be interpreted as the return address for usleep() ● This will cause a crash on return from usleep(), but the purpose here is to enter the function ● This address will make you a 1337 h4x0r – If the guess is correct, the value 0x will be interpreted as the argument for usleep() ● Hex for 16,843,009 decimal, or about 16 seconds. Obtaining the value of delta_mmap

● Iteration of one probe ● When ap_getline() returns: – If the guess is incorrect, the child process will segfault. ● This will cause Apache to fork() a new child process. However, this new process will have the same randomization as the old one (PaX randomization occurs when the parent process starts). ● Thus, we just guess again Obtaining the value of delta_mmap

● We can now compute the addresses in libc of all other functions with certainty ● Use the same buffer overflow exploit (to obtain delta_mmap) to conduct a return-to-libc attack. ● We initially start in the stack frame for the ap_getline() function. ● The overflow causes the ap_getline() function to return to a sequence of ret instructions, the address of which can be any ret instruction found in libc After obtaining delta_mmap

● Sequence of events: – The 64 byte buffer in ap_getline() is overflowed by using strcpy() to copy the attack buffer into it. – EIP for ap_getline()'s (current) stack frame is overwritten (due to the overflow) with the address of a ret instruction from libc. – When ap_getline() returns, the address in EIP is a pointer to a ret instruction! ● Remember, when ret is called for the ap_getline() function, EIP is popped off the stack and into the EIP register ● This results in a 32-bit word (address) being popped off the stack (from the EIP location) After obtaining delta_mmap

● Sequence of events: – When EIP is popped off the stack, execution jumps to the address contained in the EIP register (what was popped) ● In our case though, this address is a pointer to a ret instruction in libc! – Thus, the ret instruction pops EIP off the stack again, and again, this address is a pointer to a ret instruction! – What we are doing is essentially shifting the stack downwards one address at a time until we hit the address of system() (part of the attack buffer) After obtaining delta_mmap

● Sequence of events: – When we have popped enough of the stack to reach system(), then we know that the pointer to the 64 byte buffer will be in position to serve as the argument to system(). ● Why? Because we know the stack layout doesn't change, and thus we can figure out exactly how many ret instructions to put in the attack buffer so that system()'s address will be exactly two words down in the stack from the 64 byte buffer pointer – The pointer to the 64 byte buffer can be found in the stack frame for ap_getline()’s calling function, and thus we overflow all stack frames with ret instructions until we hit the stack frame for ap_getline()’s calling function. After obtaining delta_mmap

● What does the attack buffer look like? – First 64 bytes: the shell command that we want system() to execute – This is followed by a series of ret instructions ● These are pointers to any ret instruction found in libc ● We already know the addresses of ret functions in libc After obtaining delta_mmap

● What does the attack buffer look like? – Above the last ret instruction is the address of system() – We have just enough ret instructions to 'eat up' the stack such that we reach the 64 byte buffer in position to be the argument for system() After obtaining delta_mmap

● What does the attack buffer look like? – Again we use 0xDEADBEEF to overwrite EBP for the current stack frame and for the return address of system() – The pointer into the 64 byte buffer is not overwritten!! ● We need this for our arg to system()!! After obtaining delta_mmap

● Sequence of events: – Thus, when system() is called, the pointer to the 64 byte buffer (which contains say “/bin/sh”) is passed as an argument to system() After obtaining delta_mmap

● Why do we need to use pointers to ret instructions? Couldn't we use say replace the ret addresses with 0xDEADBEEF (or some other 1337 address) instead and simply overwrite the EIP of ap_getline()'s stack frame with the address in the stack where we overflowed with the system() address? Wouldn't this allow us to jump directly to the correct place in the stack without having to pop words to get there? – Sure, but how are we going to get that stack address? – PaX ASLR randomizes 24-bits for stack addresses – That would require 2^24 = 16,777,216 guesses of the offset alone in the worst case to figure out this stack address!! Not feasible to simply jump to this address. – But, the stack layout is not randomized (as mentioned) After obtaining delta_mmap

● 2.4 GHz Pentium 4 client attacking an Athlon 1.8GHz server. – Connected over a 100Mbps network ● Each probe resulted in about 200 bytes of network traffic – Total of 12.8MB in the worst case – Total of 6.4MB in the average case Experimental Platform

● 10 Trials ● Total # of Apache child processes spawned concurrently: 150 ● Results (of 10 trials): – Slowest time: 810 seconds – Average time: 216 seconds – Quickest time: 29 seconds Experimental Results

Improvements Attacks exploited the low entropy of 16 bits Address space layouts are randomized only at program loading

64 bit architectures 16 bits of address space randomization can be defeated by brute force 64 bits is good as 40 address bits are available for randomization Online brute force attack wont go unnoticed

Randomization frequency More frequency of randomization Re-randomizing adds no more than 1 bit of security against brute force. Increase the frequency

Randomization granularity Finer granularity by increasing randomness By randomizing functions and variable addresses within memory segments In addition to randomizing base addresses

Randomizing at Compile time Compiler and linker can be modified to randomize variables and function addresses within their segments Introduction of random padding By placing entry points in random order within a library additional bits of entropy

Randomizing at runtime Randomizing more than 16 bits but prevent the fragmentation of virtual address space. Function re-ordering within shared library Effective against return-to-libc attacks.

Modifying the compiler and linker, relative jumps can be eliminated at compile time. Defer resolution of offsets until runtime dynamic linking Allows to order functions arbitrarily and loading from different libraries also non-contiguous portions of virtual memory

Library pages differ from each processes Clustering functions into page size groups and shuffling groups instead of individual functions. Code that need to call these functions must be able to locate them effectively Global Offset Table(GOT) and array of pointers initialized by runtime dynamic linker need to be fixed..

Difficult with all the constraints. Designing a linking architecture that facilitates function shuffling in shared code pages effectively n securely is needed. Further research in this area is needed.

Monitoring and catching errors Crash detection and reaction mechanism called Watcher. Attacker incorrect guesses will trigger segmentation violations. But limited actions of crash watcher