Buffer Overflow Attack Proofing of Code Binary Gopal Gupta, Parag Doshi, R. Reghuramalingam, Doug Harris The University of Texas at Dallas

Buffer Overflow Attacks Buffer Overflow Attacks (B.O.A): A majority of attacks for which advisories are issued are based on B.O.A. Other forms of attacks, such as distributed denial of service attacks, sometimes rely on B.O.A. B.O.A. exploit the memory organization of the traditional activation stack model to overwrite the return address B.O.A. becomes possible due to bad SW engg practices Software purchaser has no way to prevent these bad practices and really can’t do much.

Security Concern Percentage of buffer overflows listed in CERT advisories each year Some examples include Windows 2003 server, sendmail, windows HTML conversion library Buffer Overflows Per Year as listed by CERT

Most Recent Warning Microsoft Windows animated cursor stack buffer overflow Public Date: March 29, 2007 Date Last Updated: April 4, 2007 Source: US-CERT Impact A remote, unauthenticated attacker may be able to execute arbitrary code or cause a denial-of-service condition System affected Microsoft Windows 2000 SP4 through Vista Overview Microsoft Windows contains a stack buffer overflow in the handling of animated cursor files. This vulnerability may allow a remote attacker to execute arbitrary code or cause a denial-of-service condition.

Background – Memory Layout Lower Memory Location Higher Memory Location Code Data Heap Stack Base Pointer Local Data Return Address Function Arguments Memory write direction Stack growth

Background – Function Call Sample Code void foo( char * Arg1) { char Buffer[64]; } void main ( ) { foo( “abc” ); } Stack Base Pointer Local Data Return Address Function Arguments Stack Frame of main function Base Pointer Local Data – Buffer[64] Return Address Function Arguments – “abc” Stack Frame of foo function ESP EBP ESP EBP

Buffer Overflow – Example Sample Code void fn (char *str) { char buffer[8]; strcpy (buffer, str); } void main( ) { char LargeString[256] ; for (int i=0; i<255; i++) LargeString [i] = ‘A’; fn(LargeString); } Stack LargeString = not initialized Base Pointer Return Address Function Arguments ESP EBP bytes long data Buffer = not initialized Base Pointer Return Address Pointer to LargeString ESP EBP Return address has changed !!!!

Issues in tackling BOA Do I have to modify my hardware? Do I have to modify my executable code? Do I have to modify my source code? Do I have to modify my compiler? Do I have to modify all of the above?

Buffer Overflow Solutions RAD: Ret. Addr. Defender stores return addr. in RAR area Impl. as a gcc compiler patch. All code has to be recompiled Stackguard: Stackguard inserts a ‘canary’ word to protect return address The ‘canary’ word can be compromised Propolice: stackguard + place buffers after pointers Same weaknesses as stackguard Splint: Splint allows the user to write annotations in the code that define allocated and used sizes User is required to write annotations Wagner’s Prevention Method: Static analysis solution Depends on source code availability

Buffer Overflow is achieved by overwriting the return address If a return address is recorded in a separate area, away from the buffer overflow, then it cannot be overwritten So modify the memory organization to add a new auxiliary return address stack, allocated in an area opposite to the direction of buffer write/overflow When a function call returns, it uses the return address from this new stack Transform the binary to make it consistent with this new memory organization. BinarySecure: An Overview

The return address is saved as part of the program execution stack This stack is uncompromised as memory writes occur in the opposite direction Lower Memory Location Higher Memory Location Code Data Heap Stack Base Pointer Local Data Return Address Function Arguments Memory write direction New Stack Stack growth direction

BinarySecure: An Overview Executable file Opcodes to be modified Disassembled file & Metadata Code flow graph Executable file Opcodes to be modified Code flow graph Executable with Modified opcodes Final executable with new instructions Executable file Disassembled file & Metadata Step - 1 Step – 2 Step - 3

Binary Secure: Specifications These are some of the conditions that must hold Code must be re-entrant Code should not modify the stack pointer Processor: Intel x386 Compiler: Dev C++ compiler Platform: Windows

Advantages Binary code is analyzed. This can be used on third-party software where one does not have access to source code. Run-time checks require modification to the source code (Splint) Compiler modifications are costly and performing changes to all available compilers is not possible. (RAD, Stackguard) Return addresses are stored on the stack itself. Hence overhead incurred while accessing addresses in other areas is reduced.

Unresolved Problems Off by One Instead of return address, attacker targets base address, i.e., EBP. Caller’s Frame Buffer Local Data EBP EIP Function Arguments Caller’s Frame Buffer Local Data EBP EIP Function Arguments Before buffer overflow stored EBP points to caller’s frame After buffer overflow stored EBP points to somewhere inside frame

Unresolved Problems Function Pointers Vulnerability Buffer overruns may change local function pointers Virtual function tables and Call back functions are also vulnerable. Stack Buffer Function Pointer Function Argument Return Address EBP Some Function Before buffer overflow Function Pointer points to some function in program Stack Buffer Function Pointer Function Argument Return Address EBP Some Function Other Function After buffer overflow stored Function Pointer points to other malicious function

Unresolved Problems Format String Attack Sprintf and its variants in C and its derivatives use variable number of arguments; attacker can exploit format tokens in first argument and gain control of the system. The attacker can perform arbitrary writes in the stack and exploit any of previous vulnerabilities.

New Approach – Split Stack Higher Memory Location Lower Memory Location Code – Static Data Data Stack Non FP – Local Data Data Base Pointer Control Stack Non FP Arguments Memory write direction Stack growth direction Function Pointers Control Base Pointer Return Address Arguments with FPs Problems Off by One Have to protect base pointer as it is main target in this attack. Function Pointer Vulnerability Have to protect function pointers in local data. Solution Split stack in two part One part contains ‘data’ Other part has ‘control’ Store control in opposite to memory write direction Heap

Current State Split Stack follows same approach as Binary Secure but eliminates more vulnerabilities. Technique currently being evaluated; system for transforming the binary to be implemented (Doshi’s MS thesis; in progress). Issue: in splitting stack would be to detect function pointers. Solution?: keep all function pointers (incl. GOT) in control stack. Keep all other pointers and data in data stack

Questions…