nd Joint Workshop between Security Research Labs in JAPAN and KOREA Annulling Data Injection Attacks with Return Address Randomization Researcher: Deokjin Kim Presenter: Cheolsoon Yim High Performance Computing Laboratory, POSTECH, Republic of KOREA

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 2/16 Contents  Introduction  Backgrounds  Related Works  Proposed Scheme  Analysis  Conclusion & Future Work

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 3/16 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

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 4/16 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 1. Overflowing the vulnerable buffer 2. Redirecting control flow to the position intended by attacker  Classification of buffer overflow attacks 1. Code-injection attack inserts instruction codes(shellcode) and jumping into it. 2. Data-injection attack inserts data(arguments of function) and jumping into shared libraries.

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 5/16 buffer frame pointer RA=XXXX buffer frame pointer RA=XXXX Backgrounds (2/2) buffer frame pointer RA=XXXX system(cmd){... } int main(int argc, char *argv[]) { char buffer[20]; strcpy(buffer, argv[1]); return 0; } dummy buffer overflowed RA=YYYY shellcode * : Overflowed region * RA : Return address High Address Low Address NormalCode-injection attackData-injection attack faked RA 1 st argument “/bin/sh\0” buffer overflowed RA=ZZZZ * In standard C library * * Vulnerable program code *

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 6/16 Related Works (1/3)  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. buffer Return Addr. High Address Low Address Stack of a process canary local variable Stack Growth String Growth

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 7/16 Related Works (2/3)  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. void main() { char buffer[20];... strcpy(buf, input_string);... } 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().... } void *memcpy(void *dest, const void *src, size_t n) {... } Program code Libsafe library Original libc library

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 8/16 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.

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 9/16 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 Code from binary file Injected code from network Normally executing SIGILL fault !! In memory = XORing LoadingFetching

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 10/16 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. Random key Return address (address of next instruction) Return address in injected code Normally executing SIGSEGV fault !! Stack section in memory = XORing pushed injected popped CALLRET

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 11/16 Proposed Scheme (3/5)  We modified CALL, RET micro-instructions. ANI : Address of Next Instruction RANI : Randomized Address of Next Instruction TR: Temporary Register instr.OriginalModified CALL func() 1. push ANI into [%esp] 2. jump to func() 1. Randomize ANI 2. push RANI into [%esp] 3. jump to func() RET1. pop from [%esp] into %eip 2. jump to %eip 1. pop from [%esp] into TR 2. De-randomize TR 3. move TR to %eip 4. jump to %eip

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 12/16  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. Proposed Scheme (4/5)

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 13/16 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=`/maps address perms offset r-xp (hello.code) a000 rw-p (hello.data) r-xp (loader.code) rw-p (loader.data) e000 r-xp (libc.code) 4212e rw-p 0012e000 (libc.data) bfffe000-c rwxp fffff000 (hello stack) 0x x code static data bss heap shared library stack kernel space 0x xffffffff loader 0x xc xbf x x SIGSEGV [ The memory map of simple process “hello” ]

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 14/16 ~/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==. ~/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 ~/exercise/ch2]$ [ Output under the RISE : protection failure ] [ Output under the proposed scheme : protection success ] Analysis - Protection against a Data-injection Attack

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 15/16 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. Type of operation RISERISARARISARA / RISE Operation of integer Operation of floating-point Operation of I/O Table. Comparison of the Execution Time Per Operation between the RISE and the proposed scheme(RISARA) [ Environment ] Linux kernel CPU : Xeon 2.66GHz*3 RAM : 2GB

nd Joint Workshop between Security Research Labs in JAPAN and KOREA 16/16 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.