Transcript PowerPoint Presentation - Buffer overflow and stack smashing attacks

Buffer overflow and stack
smashing attacks
Principles of application software
security
Breno de Medeiros
Florida State University
Fall 2005
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.
Breno de Medeiros
Florida State University
Fall 2005
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.
Breno de Medeiros
Florida State University
Fall 2005
Stack smashing
<previous stack frame>
function arguments
return address
previous frame pointer
local variables
local buffer variables
Function (subroutine) calls results
in an activation
frame being pushed
onto a memory area
called the stack.
Direction of stack growth
Breno de Medeiros
Florida State University
Fall 2005
Memory management
Stack
Direction of stack growth
Direction of heap growth
Heap
unitialized variables
initialized variables
code instructions
Breno de Medeiros
 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
Florida State University
Fall 2005
How to smash
<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
Breno de Medeiros
 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
Florida State University
Fall 2005
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.
Breno de Medeiros
Florida State University
Fall 2005
SSP
<previous stack frame>
function arguments
return address
previous frame pointer
Canary value
local buffer variables
local non-buffer variables
Direction of stack growth
Breno de Medeiros
Prevents overflow of
local non-buffer
variables
Canary value
checking only takes
place at return time,
so other attacks
possible
Florida State University
Fall 2005
Alternatives to canaries
Use a compiler that does full bounds
checking, i.e., makes sure that the code
always allocate enough memory for
arguments
Like SSP, code has to be re-compiled with
this compiler
Significant performance penalty (Java/C)
Breno de Medeiros
Florida State University
Fall 2005
Static analysis
Use a code analyzer to detect buffer
overflows
Since 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
Breno de Medeiros
Florida State University
Fall 2005
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
Breno de Medeiros
Florida State University
Fall 2005
Memory address
randomization
Patch at the kernel level, changing the
memory mapping
Small performance penalty, by extra memory
lookups (actually, extra cache lookups)
Makes it very difficult to perform a useful
buffer overflow
However, unlike some other strategies, does not
improve robustness (liveness) properties
Breno de Medeiros
Florida State University
Fall 2005