Annulling Data Injection Attacks with Return Address Randomization

Annulling Data Injection Attacks with Return Address Randomization 2006.02.20 Researcher: Deokjin Kim Presenter: Cheolsoon Yim High Performance Computing Laboratory, POSTECH, Republic of KOREA

Contents • Introduction • Backgrounds • Related Works • Proposed Scheme • Analysis • Conclusion & Future Work

Introduction • Buffer overflow vulnerability is one of the today's most serious security problems. • Many attackers are able to take the vulnerability to intrude software systems. • Various defense schemes have been proposed such as • Compiler based scheme • Dynamically loadable library based scheme • Instruction sets randomization based scheme

Backgrounds (1/2) • Buffer overflow vulnerability • A buffer which does not check the boundary in the program will be overflowed when it is stuffed with more data than it can handle. • Step of a buffer overflow attack • Overflowing the vulnerable buffer • Redirecting control flow to the position intended by attacker • Classification of buffer overflow attacks • Code-injection attack inserts instruction codes(shellcode) and jumping into it. • Data-injection attack inserts data(arguments of function) and jumping into shared libraries.

shellcode “/bin/sh\0” 1st argument dummy faked RA RA=XXXX RA=XXXX RA=XXXX RA=YYYY RA=ZZZZ frame pointer frame pointer frame pointer overflowed overflowed buffer buffer buffer buffer buffer Backgrounds (2/2) * Vulnerable program code * * In standard C library* int main(int argc, char *argv[]) { char buffer[20]; strcpy(buffer, argv[1]); return 0; } system(cmd){ ...} HighAddress * : Overflowed region * RA : Return address LowAddress Normal Code-injection attack Data-injection attack

Compiler based scheme Modifies C compiler to interpose a canary word. Ex> StackGuard, StackShield, Propolice, SplitStack Shortcoming It needs a program source code for recompilation. The methods of bypassing this scheme are explored. Related Works (1/3) StackGrowth HighAddress Return Addr. canary local variable buffer StringGrowth LowAddress Stack of a process

Dynamically loadable library based scheme Intercepts the vulnerable functions in the standard C library and uses instead its own safe implementation of the function. Ex> Libsafe Shortcoming It needs patching dynamic libraries. It can protect only C library function introduced vulnerabilities. Related Works (2/3) Program code void main() { char buffer[20]; ... strcpy(buf, input_string); ... } Libsafe library char *strcpy(char *dest, const char *src) { // Compute the length of input_string. // Compute the upper bound of size of buf(dest). // Check the bound. // Call original libc’s memcpy(). ... } Original libc library void *memcpy(void *dest, const void *src, size_t n) { ... }

Related Works (3/3) • Instruction sets randomization based scheme • Performs exclusive-or operation to instruction bytes with random keys. • It defends all typical code-injection attacks. • It dose not need recompiling and patching a kernel or a protected program. • It dose not need a program source code. • Ex> RISE/Valgrind, Boch emulator • Shortcoming • It can not cover the data-injection attacks.

Random key Random key Loading Fetching Codefrom binary file Normally executing Random key Fetching Injected codefrom network SIGILL fault !! In memory = XORing Proposed Scheme (1/5) • Instruction Set Randomization Scheme • When loading a binary image, a loader scrambles all instruction codes using a secret randomization key and loads them into memory. • When fetching instructions, the instructions are unscrambled and executed correctly.

Random key Random key pushed popped CALL RET Return address (address of next instruction) Normally executing Random key injected popped RET Return address in injected code SIGSEGV fault !! Stack section in memory = XORing Proposed Scheme (2/5) • Return Address Randomization Scheme • When calling function, CALL instruction scrambles a return address and pushes it into memory. • When returning from function, RET instruction pops a return address from memory and unscrambles it.

Proposed Scheme (3/5) • We modified CALL, RET micro-instructions. • ANI : Address of Next Instruction • RANI : Randomized Address ofNext Instruction • TR: Temporary Register

Proposed Scheme (4/5) • A random key is generated by the Linux /dev/urandom device when a program is loaded on the memory. • The key is dynamically allocated in the heap region. • We should select a random key so as to avoid infinite loops or unwilling instructions. • We should select a random key which makes the scrambled address of a injected address to lead to a memory access violation.

0xffffffff kernel space 0xc0000000 stack 0xbf000000 x shared library 0x42000000 x loader 0x40000000 SIGSEGV heap bss static data 0x08048000 code 0x00000000 Proposed Scheme (5/5) • Ex> Excluding this key • Intended address: 0x42 • Random key: 0xfd, 4a, 00 • Scrambled address: 0xbf, 08, 42 • Other random keys lead to a memory access violation. (SIGSEGV) # cat /proc/`ps -C hello -o pid=`/mapsaddress perms offset 08048000-08049000 r-xp 00000000 (hello .code) 08049000-0804a000 rw-p 00000000 (hello .data) 40000000-40015000 r-xp 00000000 (loader.code) 40015000-40016000 rw-p 00014000 (loader.data) 42000000-4212e000 r-xp 00000000 (libc .code) 4212e000-42131000 rw-p 0012e000 (libc .data) bfffe000-c0000000 rwxp fffff000 (hello stack) [ The memory map of simple process “hello” ]

Analysis - Protection against a Data-injection Attack [ Output under the RISE : protection failure ] [elitemir@gt40 ~/exercise/ch2]$ rise ./vulne `perl -e 'print "ABCD"x7 . "\x60\x33\x17\x40"."\xb0\xe7\x15\x40"."\xc3\xfe\xff\xbf";'` ==15566== RISE, for x86-linux. ==15566== buffer is at 0xbffffa60 ==15570== RISE, for x86-linux. ==15570== sh-2.05b$ id ==15571== RISE, for x86-linux. ==15571== uid=1000(elitemir) gid=100(users) groups=100(users),10(wheel),18(audio) ==15571== . . [ Output under the proposed scheme : protection success] [elitemir@gt40 ~/exercise/ch2]$ risara ./vulne `perl -e 'print "ABCD"x7 . "\x60\x93\x05\x40"."\xb0\x47\x04\x40"."\x61\xfe\xff\xbf";'` ==18794== RISARA, for x86-linux. ==18794== buffer is at 0xbffffa30 Segmentation fault [elitemir@gt40 ~/exercise/ch2]$

Analysis - Performance • The proposed scheme executes about 1 % more slowly than RISE for the same program. • Though there is 5 times performance penalty due to implement with emulator, this penalty can be removed by implementing with supporting of hardware in the future. Table. Comparison of the Execution Time Per Operation between the RISE and the proposed scheme(RISARA) [ Environment ] Linux kernel 2.4.20 CPU : Xeon 2.66GHz*3 RAM : 2GB

Conclusion & Future work • Conclusion • We proposed a new defense scheme against both code-injection and data-injection attacks through network. • It scrambles instruction sets and return addresses using a random key. • It implemented without significant extra overheads in comparison with RISE. • Future work • We are planning to implement on hardware in the near future for decreasing overheads which incurred because of using the emulator.

Annulling Data Injection Attacks with Return Address Randomization