Buffer Overflow Attackproofing by Transforming Code Binary Gopal

Buffer Overflow Attack-proofing by Transforming Code Binary Gopal Gupta Parag Doshi, R. Reghuramalingam The University of Texas at Dallas 11/15/2004

3 rd Party Software: Risky Companies Cost But, the Integrated System has a vulnerability

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. 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 B. O. A. s and can’t do much.

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

Most Recent Warning • • Sourcefire Snort DCE/RPC Preprocessor Buffer Overflow Original release date: February 19, 2007 Last revised: -Source: US-CERT Systems Affected Snort 2. 6. 1, 2. 6. 1. 1, and 2. 6. 1. 2 Snort 2. 7. 0 beta 1 Sourcefire Intrusion Sensors version 4. 1. x, 4. 5. x, and 4. 6 x with SEUs prior to SEU 64 Sourcefire Intrusion Sensors for Crossbeam version 4. 1. x, 4. 5. x, and 4. 6 x with SEUs prior to SEU 64 Other products that use Snort or Snort components may be affected. Overview A stack buffer overflow vulnerability in the Sourcefire Snort DCE/RPC preprocessor could allow an unauthenticated, remote attacker to execute arbitrary code with the privileges of the Snort process.

BOA Prevention • B. O. A. done by exploiting the memory model used by most language implementation to overwrite return address. • This memory organization can be slightly changed so as to prevent buffer overflows overwriting return addresses. • Our system automatically transforms code binaries in accordance to this modified memory organization, thereby preventing most common forms of B. O. A. s. • Our tool can be used on third-party s/w and off-the-shelf products, & does not require access to source code

Buffer Overflow Attack-proofing • Sample Code void fn (char *a, char* b, char* c) { char buffer 1[8]; } Stack at the start ff ff ESP Stack void main( ){ fn(“foo”, “bar”, “ren”); } Heap Data 00 Code

Stack Organization: Before a Call • Sample Code void fn (char* a, char* b, char* c){ char buffer 1[8]; } Stack before a call Stack Param 3 = “ren” void main( ){ fn(“foo”, “bar”, “ren”); } Param 2 = “bar” Param 1 = “foo” Heap, Data & Code Parameters ESP

Stack Organization: After a Call • Sample Code void fn (char* a, char* b, char* c){ char buffer 1[8]; } Stack after a function call Stack Param 3 = “foo” void main( ){ fn(“foo”, “bar”, “ren”); } Param 2 = “bar” Param 1 = “ren” Return address ebp Local variables . . . Heap, Data & Code EBP ESP

Buffer Overflow • Sample Code • void fn (char *str){ char buffer 1[8]; strcpy (buffer 1, str); } Strcpy writes void main( ){ char large_str[256] ; for (int i=0; i<255; i++) large_str[i] = ‘A’; fn(large_str); Label: } New return address =4141 Stack showing buffer overflow Stack 41 41 41 Large_str (Size = 64) Label: 41 41 Return address 41 41 Pointer 41 41 Garbage ebp Buffer 1 (Size = 2)

Abusing the Buffer Overflow • Step 1: Overwrite the return address with an address that points ‘back’ to the buffer area • Step 2: Insert code that you wish to execute in the buffer area • Step 3: Buffer start of inserted code with NOP instructions • Step 4: Eliminate any null values in inserted code Stack used to abuse Buffer Overflow Stack Return Address ebp NOP mov eax, ebx add eax, 1

Buffer Overflow Solutions • RAD: RAD stores the return address in RAR area • It is a gcc compiler patch. All code has to recompiled • Stackguard: Stackguard inserts a ‘canary’ word to protect return address • The ‘canary’ word can be compromised • 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

Binary. Secure: An Overview • Buffer Overflow is achieved by overwriting the return address • If return addresses are recorded in a separate area, away from the buffer overflow, then they 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.

Binary. Secure: Return Address • The return address is saved as part of the program execution stack • The auxiliary stack is allocated at the bottom of Overflow the program stack Direction • This stack is uncompromised as memory writes occur in the opposite direction

Binary. Secure

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 x 386 Compiler: Dev C++ compiler 4. 9. 9. 1 Platform: Windows

Advantages • Binary code is analysed. 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.

3 rd Party Software: After passing through Binary Secure Transform each component downloaded WOW!!!! It works…

Questions…