Buffer Overflow Attack-proofing by Transforming Code Binary

Gopal Gupta

Parag Doshi, R. Reghuramalingam

The University of Texas at Dallas

11/15/2004

3rd Party Software: Risky

But, the Integrated System has a vulnerability

CostCompanies

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 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.6x with SEUs prior to SEU 64 • Sourcefire Intrusion Sensors for Crossbeam version 4.1.x, 4.5.x, and 4.6x 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 Codevoid fn (char *a, char* b, char* c) { char buffer1[8];

}

void main( ){

fn(“foo”, “bar”, “ren”);

}

Stack at the start

ESP

Stack

Heap

Data

Code00

ff ff ff ff

Stack Organization: Before a Call

• Sample Codevoid fn (char* a, char* b, char* c){

char buffer1[8];

}

void main( ){

fn(“foo”, “bar”, “ren”);

}

Stack before a call

Parameters

Heap, Data & Code

Param 3 = “ren”

Param 2 = “bar”

Param 1 = “foo” ESP

Stack

Stack Organization: After a Call

• Sample Codevoid fn (char* a, char* b, char* c){ char buffer1[8];

}

void main( ){

fn(“foo”, “bar”, “ren”);

}

Stack after a function call

Local variables ...

Stack

Param 3 = “foo”

Param 2 = “bar”

Param 1 = “ren”

Return address

ebp

Local variables

Heap, Data & Code

EBP

ESP

Buffer Overflow

• Sample Codevoid fn (char *str){

char buffer1[8];strcpy (buffer1, str);

}void main( ){

char large_str[256] ;for (int i=0; i<255; i++)

large_str[i] = ‘A’;

fn(large_str);Label:

}• New return address =41414141

Stack showing buffer overflow

Stack

Large_str (Size = 64)

Return address

ebp

Buffer1 (Size = 2)

Strcpy writes

41 41 41 41

41 41 41 41

41 41 41 41 41 41 41 41 41 41 41 41

Label:

Pointer

Garbage

41 41 41 41

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 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

BinarySecure: 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.

BinarySecure: Return Address

• The return address is saved as part of the program execution stack

• The auxiliary stack is allocated at the bottom of the program stack

• This stack is uncompromised as memory writes occur in the opposite direction

OverflowDirection

BinarySecure

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 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.

3rd Party Software: After passing through Binary Secure

WOW!!!! It works…

Transform each component downloaded

Questions…