C and C++ vulnerability exploits and

countermeasures

Frank Piessens
([email protected])

These slides are based on the paper:

Low-level Software Security by Example by Erlingsson, Younan and Piessens

KATHOLIEKE! Secappdev 2011 1

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 2
UNIVERSITEIT!
LEUVEN
 Introduction
An implementation-level software vulnerability is a bug in a
program that can be exploited by an attacker to cause harm
Example vulnerabilities:
SQL injection vulnerabilities (discussed before)
XSS vulnerabilities (discussed before)
Buffer overflows and other memory corruption vulnerabilities
An attack is a scenario where an attacker triggers the bug to
cause harm
A countermeasure is a technique to counter attacks
These lectures will discuss memory corruption vulnerabilities,
common attack techniques, and common countermeasures for
them
KATHOLIEKE! Secappdev 2011 3
UNIVERSITEIT!
LEUVEN
 Memory corruption vulnerabilities
Memory corruption vulnerabilities are a class of
vulnerabilities relevant for unsafe languages
i.e. Languages that do not check whether programs
access memory in a correct way
Hence buggy programs may mess up parts of
memory used by the language run-time
In these lectures we will focus on memory
corruption vulnerabilities in C programs

KATHOLIEKE! Secappdev 2011 4

UNIVERSITEIT!
LEUVEN
 Example vulnerable C program

KATHOLIEKE! Secappdev 2011 5

UNIVERSITEIT!
LEUVEN
 Introduction
Attacks that exploit such vulnerabilities can have
devastating consequences:
E.g. CERT Advisory Feb 2006:
The Microsoft Windows Media Player plug-in for browsers other than
Internet Explorer contains a buffer overflow, which may allow a remote
attacker to execute arbitrary code. (CVE-2006-005)

This is one (of the many) examples of a

vulnerability that is exploitable by a code
injection attack

KATHOLIEKE! Secappdev 2011 6

UNIVERSITEIT!
LEUVEN
 Background:
Memory management in C
Memory can be allocated in many ways in C
Automatic (local variables in functions)
Static (global variables)
Dynamic (malloc and new)
Programmer is responsible for:
Appropriate use of allocated memory
E.g. bounds checks, type checks,
Correct de-allocation of memory

KATHOLIEKE! Secappdev 2011 7

UNIVERSITEIT!
LEUVEN
 Process memory layout

High addresses Arguments/ Environment

Stack grows
Stack down

Unused and Mapped Memory

Heap grows
Heap (dynamic data)
up
Static Data

Low addresses Program Code

KATHOLIEKE! Secappdev 2011 8

UNIVERSITEIT!
LEUVEN
 Memory management in C
Memory management is very error-prone
Some typical bugs:
Writing past the bound of an array
Dangling pointers
Double freeing
Memory leaks
For efficiency, practical C implementations dont
detect such bugs at run time
The language definition states that behavior of a
buggy program is undefined
KATHOLIEKE! Secappdev 2011 9
UNIVERSITEIT!
LEUVEN
 Attacking unsafe code
To do a code injection attack, an attacker must:
Find a bug in the program that can break memory
safety
Find an interesting memory location to overwrite
Get attack code in the process memory space

KATHOLIEKE! Secappdev 2011 10

UNIVERSITEIT!
LEUVEN
 Bugs that can break memory safety
Writing past the end of an array (buffer overrun
or overflow)
Dereference a dangling pointer
Use of a dangerous API function
That internally overflows a buffer
E.g. strcpy(), gets()
That is implemented in assembly in an intrinsically
unsafe way
E.g. printf()

KATHOLIEKE! Secappdev 2011 11

UNIVERSITEIT!
LEUVEN
 Interesting memory locations
Code addresses or function pointers
Return address of a function invocation
Function pointers in the virtual function table
Program specific function pointers
Pointers where the attacker can control what is
written when the program dereferences the
pointer
Indirect pointer overwrite: first redirect the pointer to
another interesting location, then write the
appropriate value

KATHOLIEKE! Secappdev 2011 12

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 13
UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
The stack is a memory area used at run time to
track function calls and returns
Per call, an activation record or stack frame is
pushed on the stack, containing:
Actual parameters, return address, automatically allocated
local variables,
As a consequence, if a local buffer variable can
be overflowed, there are interesting memory
locations to overwrite nearby

KATHOLIEKE! Secappdev 2011 14

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Stack
Return address f0
FP Saved Frame Ptr f0
IP f0:

Local variables f0
call f1

SP

f1:
buffer[]
overflow()

KATHOLIEKE! Secappdev 2011 15

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Stack
Return address f0
Saved Frame Ptr f0
f0:

Local variables f0
call f1

Arguments f1
IP f1:
Return address f1
buffer[]
overflow() FP Saved Frame Ptr f1

Space for buffer
SP

KATHOLIEKE! Secappdev 2011 16

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Stack
Return address f0
Saved Frame Ptr f0
f0:

Local variables f0
call f1

Arguments f1
f1:
Overwritten address
buffer[]
overflow() FP
IP
Injected Code
SP

KATHOLIEKE! Secappdev 2011 17

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Shell code strings:
LINUX on Intel:
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";

SPARC Solaris:
char shellcode[] =
"\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
"\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
"\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
"\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";

KATHOLIEKE! Secappdev 2011 18

UNIVERSITEIT!
LEUVEN
 Very simple shell code
In examples further on, we will use:

KATHOLIEKE! Secappdev 2011 19

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Example vulnerable program:

KATHOLIEKE! Secappdev 2011 20

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Or alternatively:

KATHOLIEKE! Secappdev 2011 21

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Snapshot of the stack before the return:

KATHOLIEKE! Secappdev 2011 22

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Snapshot of the stack before the return:

KATHOLIEKE! Secappdev 2011 23

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Lots of details to get right before it works:
No nulls in (character-)strings
Filling in the correct return address:
Fake return address must be precisely positioned
Attacker might not know the address of his own string
Other overwritten data must not be used before
return from function

More information in
Smashing the stack for fun and profit by Aleph One
KATHOLIEKE! Secappdev 2011 24
UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 25
UNIVERSITEIT!
LEUVEN
 Heap based buffer overflow
If a program contains a buffer overflow
vulnerability for a buffer allocated on the heap,
there is no return address nearby
So attacking a heap based vulnerability requires
the attacker to overwrite other code pointers
We look at two examples:
Overwriting a function pointer
Overwriting heap metadata

KATHOLIEKE! Secappdev 2011 26

UNIVERSITEIT!
LEUVEN
 Overwriting a function pointer
Example vulnerable program:

KATHOLIEKE! Secappdev 2011 27

UNIVERSITEIT!
LEUVEN
 Overwriting a function pointer
And what happens on overflow:

KATHOLIEKE! Secappdev 2011 28

UNIVERSITEIT!
LEUVEN
 Overwriting heap metadata
The heap is a memory area where dynamically
allocated data is stored
Typically managed by a memory allocation library that offers
functionality to allocate and free chunks of memory (in C:
malloc() and free() calls)
Most memory allocation libraries store management
information in-band
As a consequence, buffer overruns on the heap can overwrite
this management information
This enables an indirect pointer overwrite-like attack
allowing attackers to overwrite arbitrary memory locations

KATHOLIEKE! Secappdev 2011 29

UNIVERSITEIT!
LEUVEN
 Heap management in dlmalloc
Top Heap
grows
with brk() Dlmalloc maintains a
doubly linked list of free
chunks
Backward pointer When chunk c gets
Forward pointer unlinked, cs backward
Other mgmt info pointer is written to *
Free chunk (forward pointer+12)
c
Or: green value is
written 12 bytes above
where red value points
User data

Other mgmt info

Chunk in use
KATHOLIEKE! Secappdev 2011 30
UNIVERSITEIT!
LEUVEN
 Exploiting a buffer overrun
Top Heap
grows
with brk() RA Green value is written
12 bytes above where
red value points
A buffer overrun in d
can overwrite the red
and green values

c Make Green point to

injected code
Make Red point 12
d
bytes below a function
return address
Stack

Heap
KATHOLIEKE! Secappdev 2011 31
UNIVERSITEIT!
LEUVEN
 Exploiting a buffer overrun
Top Heap
grows
with brk() RA Green value is written
12 bytes above where
red value points
Net result is that the
return address points to
the injected code

Stack

Heap
KATHOLIEKE! Secappdev 2011 32
UNIVERSITEIT!
LEUVEN
 Indirect pointer overwrite
This technique of overwriting a pointer that is later
dereferenced for writing is called indirect pointer
overwrite
This is a broadly useful attack technique, as it allows to
selectively change memory contents
A program is vulnerable if:
It contains a bug that allows overwriting a pointer value
This pointer value is later dereferenced for writing
And the value written is under control of the attacker

KATHOLIEKE! Secappdev 2011 33

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 34
UNIVERSITEIT!
LEUVEN
 Return-into-libc
Direct code injection, where an attacker injects
code as data is not always feasible
E.g. When certain countermeasures are active
Indirect code injection attacks will drive the
execution of the program by manipulating the
stack
This makes it possible to execute fractions of
code present in memory
Usually, interesting code is available, e.g. libc
KATHOLIEKE! Secappdev 2011 35
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory

f1
Params for f1
.
.
return
Return addr
f2
Params for f2
.
Return addr .
return
f3
Params for f3

return
Return addr
.
SP Return addr
.
IP return
KATHOLIEKE! Secappdev 2011 36
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory

f1
Params for f1
.
.
return
Return addr
f2
Params for f2
.
Return addr .
return
IP f3
Params for f3

SP return
Return addr
.
.
return
KATHOLIEKE! Secappdev 2011 37
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory

f1
Params for f1
.
.
return
Return addr
f2
Params for f2
.
Return addr .
return
f3
Params for f3
IP

SP return
Return addr
.
.
return
KATHOLIEKE! Secappdev 2011 38
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory

f1
Params for f1
.
.
return
Return addr
f2
Params for f2
.
Return addr .
return
f3
Params for f3

SP IP return
Return addr
.
.
return
KATHOLIEKE! Secappdev 2011 39
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory

f1
Params for f1
.
.
return
Return addr
IP f2
Params for f2
.
SP Return addr .
return
f3

return
.
.
return
KATHOLIEKE! Secappdev 2011 40
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory

f1
Params for f1
.
.
return
Return addr
f2
Params for f2
.
SP Return addr .
IP return
f3

return
.
.
return
KATHOLIEKE! Secappdev 2011 41
UNIVERSITEIT!
LEUVEN
 Return-into-libc: overview
Stack Code Memory
IP f1
Params for f1
.
.
return
SP Return addr
f2
.
.
return
f3

return
.
.
return
KATHOLIEKE! Secappdev 2011 42
UNIVERSITEIT!
LEUVEN
 Return-to-libc
What do we need to make this work?
Inject the fake stack
Easy: this is just data we can put in a buffer
Make the stack pointer point to the fake stack right
before a return instruction is executed
We will show an example where this is done by jumping to
a trampoline
Then we make the stack execute existing functions
to do a direct code injection
But we could do other useful stuff without direct code
injection
KATHOLIEKE! Secappdev 2011 43
UNIVERSITEIT!
LEUVEN
 Vulnerable program

KATHOLIEKE! Secappdev 2011 44

UNIVERSITEIT!
LEUVEN
 The trampoline
Assembly code of qsort:

Trampoline code

KATHOLIEKE! Secappdev 2011 45

UNIVERSITEIT!
LEUVEN
 Launching the attack

KATHOLIEKE! Secappdev 2011 46

UNIVERSITEIT!
LEUVEN
 Unwinding the fake stack
Code Memory

VirtualAlloc
.
.
return
.
.
.

InterlockedEcxh
ange

return
.
.
SP
.
KATHOLIEKE! Secappdev 2011 47
UNIVERSITEIT!
LEUVEN
 Unwinding the fake stack
Code Memory
IP VirtualAlloc
.
.
return
.
.
.

InterlockedEcxh
ange

return
SP .
.
.
KATHOLIEKE! Secappdev 2011 48
UNIVERSITEIT!
LEUVEN
 Unwinding the fake stack
Code Memory

VirtualAlloc
.
.
IP return
.
.
.

InterlockedEcxh
ange

return
SP .
.
.
KATHOLIEKE! Secappdev 2011 49
UNIVERSITEIT!
LEUVEN
 Unwinding the fake stack
Code Memory

VirtualAlloc
.
.
return
.
.
.
SP
IP InterlockedEcxh
ange

return
.
.
.
KATHOLIEKE! Secappdev 2011 50
UNIVERSITEIT!
LEUVEN
 Unwinding the fake stack
Code Memory

VirtualAlloc
.
.
return
.
.
.
SP
InterlockedEcxh
ange

IP return
.
.
.
KATHOLIEKE! Secappdev 2011 51
UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 52
UNIVERSITEIT!
LEUVEN
 Data-only attacks
These attacks proceed by changing only data of
the program under attack
Depending on the program under attack, this can
result in interesting exploits
We discuss two examples:
The unix password attack
Overwriting the environment table

KATHOLIEKE! Secappdev 2011 53

UNIVERSITEIT!
LEUVEN
 Unix password attack
Old implementations of login program looked like
this:
Stack
Password check in login program:
1. Read loginname
Hashed password 2. Lookup hashed password
3. Read password
password 4. Check if
hashed password = hash (password)

KATHOLIEKE! Secappdev 2011 54

UNIVERSITEIT!
LEUVEN
 Unix password attack

Stack
Password check in login program:
1. Read loginname
Hashed password 2. Lookup hashed password
3. Read password
password 4. Check if
hashed password = hash (password)

ATTACK: type in a password of the form pw || hash(pw)
KATHOLIEKE! Secappdev 2011 55
UNIVERSITEIT!
LEUVEN
 Overwriting the environment table

KATHOLIEKE! Secappdev 2011 56

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 57
UNIVERSITEIT!
LEUVEN
 Stack canaries
Basic idea
Insert a value right in a stack frame right before the
stored base pointer/return address
Verify on return from a function that this value was
not modified
The inserted value is called a canary, after the
coal mine canaries

KATHOLIEKE! Secappdev 2011 58

UNIVERSITEIT!
LEUVEN
 Stack canaries
Stack
Return address f0
FP Saved Frame Ptr f0
IP f0:
Canary
call f1

SP

f1:
buffer[]
overflow()

KATHOLIEKE! Secappdev 2011 59

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Stack
Return address f0
Saved Frame Ptr f0
f0:
Canary
call f1

Arguments f1
IP f1:
Return address f1
buffer[]
overflow() FP Saved Frame Ptr f1

Canary

SP

KATHOLIEKE! Secappdev 2011 60

UNIVERSITEIT!
LEUVEN
 Stack based buffer overflow
Stack
Return address f0
Saved Frame Ptr f0
f0:
Canary
call f1

Arguments f1
f1:
Overwritten address
buffer[]
overflow() FP
IP
Canary

SP

KATHOLIEKE! Secappdev 2011 61

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 62
UNIVERSITEIT!
LEUVEN
 Non-executable data
Direct code injection attacks at some point
execute data
Most programs never need to do this
Hence, a simple countermeasure is to mark data
memory (stack, heap, ...) as non-executable
This counters direct code injection, but not
return-into-libc or data-only attacks
In addition, this countermeasure may break
certain legacy applications
KATHOLIEKE! Secappdev 2011 63
UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 64
UNIVERSITEIT!
LEUVEN
 Control-flow integrity
Most attacks we discussed breaks the control
flow as it is encoded in the source program
E.g. At the source code level, one always expects a
function to return to its call site
The idea of control-flow integrity is to instrument
the code to check the sanity of the control-flow
at runtime

KATHOLIEKE! Secappdev 2011 65

UNIVERSITEIT!
LEUVEN
 Example CFI at the source level
The following code explicitly checks whether the
cmp function pointer points to one of two known
functions:

KATHOLIEKE! Secappdev 2011 66

UNIVERSITEIT!
LEUVEN
 Example CFI with labels

KATHOLIEKE! Secappdev 2011 67

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 68
UNIVERSITEIT!
LEUVEN
 Layout Randomization
Most attacks rely on precise knowledge of run
time memory addresses
Introducing artificial variation in these addresses
significantly raises the bar for attackers
Such adress space layout randomization (ASLR)
is a cheap and effective countermeasure

KATHOLIEKE! Secappdev 2011 69

UNIVERSITEIT!
LEUVEN
 Example

KATHOLIEKE! Secappdev 2011 70

UNIVERSITEIT!
LEUVEN
 Overview
Introduction
Example attacks
Stack-based buffer overflow
Heap-based buffer overflow
Return-to-libc attacks
Data-only attacks
Example defenses
Stack canaries
Non-executable data
Control-flow integrity
Layout randomization
Conclusion
KATHOLIEKE! Secappdev 2011 71
UNIVERSITEIT!
LEUVEN
 Overview

KATHOLIEKE! Secappdev 2011 72

UNIVERSITEIT!
LEUVEN
 Conclusion
The design of attacks and countermeasures has
led to an arms race between attackers and
defenders
While significant hardening of the execution of C-
like languages is possible, the use of safe
languages like Java / C# is from the point of view
of security preferable

KATHOLIEKE! Secappdev 2011 73

UNIVERSITEIT!
LEUVEN
 Conclusion
The automatic defenses discussed in this
lecture are only one element of securing C
software
Secure software development also entails:
Threat modeling: what parts of the program are most
likely to be under attack
Code review: to detect and eliminate bugs
Security testing

KATHOLIEKE! Secappdev 2011 74

UNIVERSITEIT!
LEUVEN
 Attack exercises
Exercises
Taken from (or based on) Geras Insecure
Programming Page:
http://community.corest.com/~gera/InsecureProgramming/
For each of the following exercises:
Draw the layout of the stack at the point where gets() is
executed
What input makes the program print out you win!?

KATHOLIEKE! Secappdev 2011 75

UNIVERSITEIT!
LEUVEN
 Attack exercises
Exercise 1:
#include <stdio.h>
int main() {
int cookie;
char buf[80];
printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);
if (cookie == 0x41424344)
printf("you win!\n");
}

KATHOLIEKE! Secappdev 2011 76

UNIVERSITEIT!
LEUVEN
 Attack exercises
Exercise 2:
#include <stdio.h>
int main() {
int cookie;
char buf[80];
printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);
}

KATHOLIEKE! Secappdev 2011 77

UNIVERSITEIT!
LEUVEN