Transcript Methods of Protecting the Stack Overflow Vulnerability Aiman Rasheed Department: ICS KFUPM, Dhahran, KSA May 4, 2004

Methods of Protecting the
Stack Overflow Vulnerability
Aiman Rasheed
Department: ICS
KFUPM, Dhahran, KSA
May 4, 2004
Agenda













Introduction
What are Buffer Overflows?
How Severe are Buffer Overflows
Recent Buffer Overflow Vulnerabilities
Most Severe Buffer Overflow Vulnerabilities
Requirements to Launch an Attack
Attack Goals
Attack Targets
Benefits an Attacker may get
Protection Mechanism
Solutions Based Taxonomy
Proposed Strategy
Conclusion
Introduction


Operations happening at Function Call
Stack Structure
Introduction
Operations happening at Function Call






The function’s parameters are saved onto the stack
The caller’s registers are also saved onto the stack
The return address is saved onto stack
Execution is transferred to the called function.
Once the function completes its task, it jumps back to the
return address saved on the stack
Introduction

Stack Structure
What are Buffer Overflows?


Source data more than destination data while
copying
No checking for data limit
DST
SRC
What are Buffer Overflows?

A simple example;
void main(){
char bufferA[256];
myFunction(bufferA); }
void myFunction(char *str) {
char bufferB[16];
strcpy(bufferB, str); }
Attack Example
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";
char large_string[128];
void main(){
char buffer[96];
int i;
long *long_ptr = (long *) large_string;
for (i = 0; i < 32; i++)
*(long_ptr + i) = (int) buffer;
for (i = 0; i < strlen(shellcode); i++)
large_string[i] = shellcode[i];
strcpy(buffer,large_string);
}
Example
Example
How Severe are Buffer Overflows
40
35
30
Total Vulnerabilities
Buffer Overflow Vulnerabilities
25
20
15
10
5
0
1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002
Year
Recent Vulnerabilities
S.
No
Date
(MM/DD/Y
YYY)
1
4/02/2004
Microsoft Internet Explorer does not properly validate URL sources
2
4/01/2004
ModSecurity for Apache vulnerable to off-by-one overflow when
directive "SecFilterScanPost" is enabled
3
3/23/2004
HP-UX "libDtSvc" vulnerable to buffer overflow
4
3/19/2004
Apache mod_rewrite vulnerable to buffer overflow via crafted regular
expression
5
3/19/2004
Apache mod_alias vulnerable to buffer overflow via crafted regular
expression
Vulnerability Name
Most Severe Vulnerabilities
S.
No
Date
(MM/DD/Y
YYY)
1
11/10/99
BIND T_NXT record processing may cause buffer overflow
2
2/08/2001
SSH CRC32 attack detection code contains remote integer overflow
3
9/10/2003
Microsoft Windows RPCSS Service contains heap overflow in DCOM
request filename handling
4
9/10/2003
Microsoft Windows RPCSS Service contains heap overflow in DCOM
activation routines
5
6/23/2000
Format string input validation error in wu-ftpd site_exec() function
Vulnerability Name
Requirements to Launch an Attack



Size of the buffer must be determined
Must be able to control the data written into
the buffer
There must be security sensitive variables or
executable program instructions stored below
the buffer in stack
Attack Goal


Insert malicious code also known as ‘Code
Injections’
Change the execution path of a program
Attack Targets

Return Address


Overwriting the Return Address of a function with
that of an Attack code
Function Pointer

Overwriting the Function Pointer with an address
of Attack code
Benefits an Attacker may get!






Change privilege from normal user to super user
Launch DOS ( Denial of Service) Attacks
Crash an application, or may cause it to give
incorrect results
Launch any Malicious Code fruitful for an attacker
Get a remote control on the machine
Corrupting application in order to disclose
confidential information
Protection Mechanism

Static Approaches


Requires the analysis of source code for detection
and removal of vulnerabilities
Dynamic Approaches

Run time preventive measurements
Protection Mechanism

Static Approaches




Need updated database of programming flaws to
test for
Need source code recompilation for updated
applications
Existing vulnerable libraries need to be
recompiled again as well
Useful for applications that are being developed
Protection Mechanism

Dynamic Approaches



Need database of known attacks
No need of recompilation of source code or
libraries
It can be applied to legacy systems
Protection Mechanism
Static Approaches
Dynamic Approaches
ITS4
StackGuard
Integer range analysis
Stack Shield
Source to source transformations
Stack Ghost
Cyclone
Libsafe
CCured
Libverify
Gemini
ProPolice
RAD
Purify
Point Guard
Valgrind
Solution Based Taxonomy

Return Address Protection




Access Violation Probing



Canary Insertion
Guard Value
Return Address Repository
Code Segment Boundary Checking
Run-time Memory Access Checking
Bounds Checking


Array Bounds Checking
Source to Source Transformation
Solution Based Taxonomy

Return Address Protection

Canary Insertion


A dummy value between previous
frame pointer and return address
Upon returning if Canary is
tampered, buffer overflow is
detected
Arguments
Return Address
Canary
Prev. frame pointer
Local variables
Solution Based Taxonomy

Return Address Protection

Canary Insertion, some ways to circumvent



Keep the Canary as intact; overwriting it with the same
value
Jump over it using an abused pointer
Counter solutions


Random Canary
Terminator Canary as NULL character, -1, carriage
return and line feed etc
Solution Based Taxonomy

Return Address
Protection

Guard Value


Similar to Canary value
Rearrangement of stack
contents; i.e. charter
buffer come before all
other variables and just
after Guard value
Solution Based Taxonomy

Return Address Protection

Return Address Repository


At every function call, new stack frame is created and
copy of return address is saved
When the function returns;



Copy of Return Address is retrieved
Retrieved copy is compared with Return Address
Examples;

StackGuard, Propolice,Libverify, etc
Solution Based Taxonomy

Access Violation Probing

Code Segment Boundary Checking




To make it assured before executing any code that it
belongs to the code segment
Storing a global variable in data segment and its
address is taken as boundary value
Any reference outside this boundary value is taken as
malicious activity
Example; StackShield
Solution Based Taxonomy

Access Violation Probing

Run-time Memory Access Checking



Concerns incorrect read and/or write to memory
locations
Referring to block of memory which is already deallocated
Examples; Valgrind, Cyclone, Purify etc
Solution Based Taxonomy

Bounds Checking

Array Bounds Checking



Useful technique for code injection attacks protection
Needs manual checking to look for illegal buffer
assignments
Keeping array limits for checking
Solution Based Taxonomy

Bounds Checking

Source to Source Transformation






Used to detect unsafe string operations
Programs are instrumented with additional variables
Instrumented variables describe string attributes
Such variables are checked statically
Space complexity is increased
Good for small scale applications
Proposed Strategy

Memory Mirror




A bit acting as mirror against every memory locations
Set the bit corresponding to memory location containing
return address
Overwriting of return address will be protected as bit is
already set
It works as atomic mutex
Proposed Strategy
Conclusion





In today’s computing environment, one of the most
common ways of breaching system security is Buffer
Overflow
Two basic approaches are Static and Dynamic
Overlapping solutions can be categorized as; Return
Address Protection, Access Violation Probing and
Bounds Checking
Performance criteria decides whether to use the
solution as a debugging tool or as normal
application
A Memory Mirror approach is presented to enhance
security of a system
Special Thanks
Dr. Khalid Salah
&
Syed Zeeshan Muzaffar
Thank You
Q&A