Buffer overflow and stack smashing attacks

Principles of application software security

Buffer overflows

One of the most common vulnerabilities in software

Particularly problematic when present in system libraries and other code that runs with high execution privileges.

How it works

Application reserves adjacent memory locations (buffer) to store arguments to a function, or variable values.

Attacker gives an argument too long to fit in the buffer. The application copies the whole argument,

overflowing the buffer and overwriting memory space. If the conditions are “just right” this will enable to

attacker to gain control over the program flow and execute arbitrary code, with the same privileges of the original application.

Stack smashing

Function (sub-routine) calls results in an activation frame being pushed onto a memory area called the stack.

<previous stack frame>function arguments

return address

previous frame pointer

local variableslocal buffer variables

Direction of stack growth

Memory management

The stack, which contains activation frames, starts at the highest memory address allocated for the process, and grows downwards

Variable-length data (e.g., strings) that are read dynamically, are kept in the heap, which grows upwards

This arrangement maximizes flexibility of virtual memory management

Stack

Heapunitialized variables

initialized variables

code instructions

Direction of stack growth

Direction of heap growth

How to smash

Give application a very long string with malicious code

The string length, being much larger than the space allocated in the heap (buffer size declaration) causes the heap to overflow into the stack and overwrites the return address

The return address now points to the beginning of the malicious code

<previous stack frame>

function arguments

Return address (overwritten with

entry address of malicious code) Previous frame pointer

(overwritten w/ malicious code)local variables (overwritten w/

malicious code)local buffer variables

(overwritten w/ malicious code)Direction of stack growth

(a) Basic stack overflow C code

(b) Basic stack overflow example runs

Figure 10.5 Basic Stack Overflow Example

$ cc -g -o buffer2 buffer2.c

$ ./buffer2Enter value for name: Bill and Lawrie Hello your name is Bill and Lawrie buffer2 done

$ ./buffer2Enter value for name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Segmentation fault (core dumped)

$ perl -e 'print pack("H*", "41424344454647485152535455565758616263646566676808fcffbf948304080a4e4e4e4e0a");' | ./buffer2Enter value for name:Hello your Re?pyy]uEA is ABCDEFGHQRSTUVWXabcdefguyuEnter value for Kyyu: Hello your Kyyu is NNNN Segmentation fault (core dumped)

void hello(char *tag){char inp[16];

printf("Enter value for %s: ", tag);gets(inp);printf("Hello your %s is %s\n", tag, inp);}

Memory Before After ContainsAddress gets(inp) gets(inp) Value of

. . . . . . . . . . . .

bffffbe0 3e850408 00850408 tag> . . . . . . .bffffbdc f0830408 94830408 return addr. . . . . . . .bffffbd8 e8fbffbf e8ffffbf old base ptr. . . . . . . . bffffbd4 60840408 65666768` . . . e f g h

bffffbd0 30561540 616263640 V . @ a b c dbffffbcc 1b840408 55565758 inp[12-15]. . . . U V W Xbffffbc8 e8fbffbf 51525354 inp[8-11]. . . . Q R S Tbffffbc4 3cfcffbf 45464748 inp[4-7]< . . . E F G Hbffffbc0 34fcffbf 41424344 inp[0-3]4 . . . A B C D

. . . . . . . . . . . .

Figure 10.6 Basic Stack Overflow Stack Values

StackOverflowExample

(a) Another stack overflow C code

(b) Another stack overflow example runs

Figure 10.7 Another Stack Overflow Example

$ cc -o buffer3 buffer3.c

$ ./buffer3Input value: SAFEbuffer3 getinp read SAFEread val: SAFEbuffer3 done

$ ./buffer3Input value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX buffer3 getinp read XXXXXXXXXXXXXXX read val: XXXXXXXXXXXXXXX

buffer3 doneSegmentation fault (core dumped)

void getinp(char *inp, int siz){puts("Input value: ");fgets(inp, siz, stdin);printf("buffer3 getinp read %s\n", inp);}

void display(char *val){char tmp[16];sprintf(tmp, "read val: %s\n", val);puts(tmp);}

int main(int argc, char *argv[]){char buf[16];getinp(buf, sizeof(buf)); display(buf); printf("buffer3 done\n");}

Canary Guards

Like the legendary canary-in-the-mine, it detects stack smash attacks.

Inserts a “Canary value” just below the return address (Stack Guard) or just below the previous frame pointer (Stack Smashing Protector). This value gets checked right before a function returns.

SSP

Prevents overflow of local buffer variables

Canary value checking only takes place at return time, so other attacks possible

<previous stack frame>function arguments

return address

previous frame pointer

local buffer variables

local non-buffer variables

Direction of stack growth

Canary value

Alternatives to canaries

Use a compiler that does full bounds checking, i.e., makes sure that the code always allocate enough memory for argumentsSignificant performance penalty (Java/C)

Static analysis

Use a code analyzer to detect buffer overflowsSince checking that arbitrary code does not

overflow is an undecidable problem, the code must be annotated in order for this to work Depends on programmer expertise (costly) Some common and useful programming techniques are

prohibited (performance and engineering costs)

Advantage is that the compiled code does not suffer from performance deterioration

Safe libraries

Many vulnerabilities in code are due to unsafe use of system libraries

An alternative is to install a kernel patch that dynamically substitutes calls to unsafe library functions for safe versions of those

Not possible for closed-source systems such as MS operating systems

Memory address randomization

Patch at the kernel level, changing the memory mappingSmall performance penalty, by extra memory

lookups (actually, extra cache lookups)

Makes it very difficult to perform a useful buffer overflowHowever, unlike some other strategies, does not

improve robustness (liveness) properties