CS-3002: Information Security
Control Hijacking Attacks and Defenses
Prof. Dr. Sufian Hameed
Department of Computer Science
FAST-NUCES
FAST-NUCE
S
This Lecture
⚫ Basic Control Hijacking
Attacks
⚫ More Control Hijacking Attacks
⚫ Format String Bugs
⚫ Platform Defenses
⚫ Run-Time Defenses
⚫ Advance Hijacking Attacks
FAST-NUCE
S
Basic Control Hijacking
Attacks
FAST-NUCE
S
Control hijacking attacks
⚫ Attacker’s goal:
⚫ Take over target machine (e.g. web server, email server
…)
⚫ Execute arbitrary code on target by hijacking application
control flow
⚫ Examples.
⚫ Buffer overflow attacks
⚫ Integer overflow attacks
⚫ Format string vulnerabilities
FAST-NUCE
S
What is needed
⚫ Understanding C functions, the stack, and the heap.
⚫ Know how system calls are made
⚫ The exec() system call
⚫ Attacker needs to know which CPU and OS used on the target
machine:
⚫ Our examples are for x86 running Linux or Windows
⚫ Details vary slightly between CPUs and OSs:
⚫ Little endian vs. big endian (x86 vs. Motorola)
⚫ Stack Frame structure (Unix vs.
Windows)
FAST-NUCE
S
Linux process memory layout
0xC000000
user stack 0
%es
p
shared libraries
0x4000000
0
br
k run time heap
Loaded
from 0x0804800
exec unused
0
FAST-NUCE
S
0
Stack Frame (created every time a new function is invoked)
hig
h
argument
s
return address
stack frame pointer
exception handlers
local variables Stack
Growt
callee saved registers
S h
lo
P w
FAST-NUCE
S
What are buffer overflows?
Suppose a web server contains a function: void func(char *str) {
char buf[128];
When func() is called stack looks like: strcpy(buf, str);
do-something(buf);
argument: }
str
return address
stack frame
pointer
char buf[128]
S
P
FAST-NUC
ES
What are buffer overflows?
What if *str is 136 bytes void func(char *str) {
After long? char buf[128];
strcpy: strcpy(buf, str);
do-something(buf);
argument: str }
return address
stack frame pointer
*st
r
char buf[128] Problem:
no length checking in strcpy()
S
P
FAST-NUC
ES
Basic stack exploit
hig
Suppose *str is such h
that Program P
after strcpy stack looks
like:
(exact shell code by Aleph One)
Program P:
exec(“/bin/sh”)
When func() exits, the user gets return address
shell ! Note: attack code P runs in stack.
char buf[128]
lo
FAST-NUCE w
S
The NOP slide hig
h
Problem: how does attacker Program P
determine ret-address?
Solution: NOP slide NOP Slide
⚫ Guess approximate stack state
when func() is called
⚫ Insert many NOPs before program P:
nop , xor eax,eax , inc ax return address
⚫ nop: Basic no-operation instruction.
⚫ xor eax, eax: A harmless operation that does
nothing significant but consumes CPU time.
char buf[128]
⚫ inc ax: A lightweight arithmetic instruction.
lo
FAST-NUCE w
S
Details and examples
⚫ Some complications:
⚫ Program P should not contain the ‘\0’ character.
⚫ Overflow should not crash program before func()
exists.
FAST-NUCE
S
Many unsafe libc functions
strcpy (char *dest, const char *src)
strcat (char *dest, const char *src)
gets (char *s)
scanf ( const char *format, … ) and many more.
⚫ “Safe” libc versionsstrncpy(), strncat()are misleading
⚫ e.g. strncpy() may leave string unterminated.
⚫ Windows C run time (CRT):
⚫ strcpy_s (*dest, DestSize, *src): ensures proper termination
FAST-NUCE
S
Finding buffer overflows
⚫ To find overflow:
⚫ Run web server on local machine
⚫ Issue malformed requests (ending with “$$$$$” )
⚫ Many automated tools exist (called fuzzers – next module)
⚫ If web server crashes
⚫ search core dump for “$$$$$” to find overflow location
(heap, stack)
⚫ Construct (not easy given latest
exploit defenses)
FAST-NUCE
S
More Control Hijacking
Attacks
FAST-NUCE
S
More Hijacking Opportunities
⚫ Integer overflows: (e.g. Use to attack MS DirectX MIDI Lib)
⚫ Double free: double free space on heap.
⚫ Can cause memory mgr to write data to specific location
⚫ Examples: CVS server
⚫ Format string vulnerabilities
FAST-NUCE
S
Integer Overflows (Phrack issue 60)
Problem: what happens when int exceeds max value?
int m; (32 bits) short s; (16 bits) char c;(8 bits)
c = 0x80 + 0x80 = 128 + 128 ⇒ c=0
s = 0xff80 + 0x80 ⇒ s=0
m = 0xffffff80 + 0x80 ⇒ m=0
Can this be exploited?
FAST-NUCE
S
An example
void func( char *buf1, *buf2, unsigned int len1, len2) {
char temp[256];
if (len1 + len2 > 256) {return // length check
-1} memcpy(temp, buf1, len1); // cat buffers
memcpy(temp+len1, buf2, len2);
do-something(temp); // do stuff
}
What if len1 = 0x80, len2 = 0xffffff80 ?
⇒ len1+len2 = 0
Second memcpy() will overflow heap !!
FAST-NUCE
S
Format String Bug
FAST-NUCE
S
Format string problem
int func(char *user) {
fprintf( stderr, user);
}
Problem: what if *user = “%s%s%s%s%s%s%s” ??
⚫ Most likely program will crash: DoS.
⚫ If not, program will print memory contents. Privacy?
⚫ Full exploit using user = “%n” (directive to allow writing in
memory)
⚫ Correct form (always be explicit about your format
string ): fprintf( stdout, “%s”, user);
FAST-NUCE
S
Vulnerable functions
Any function using a format string.
Printing:
printf, fprintf, sprintf, …
vprintf, vfprintf, vsprintf, …
Logging:
syslog, err, warn
FAST-NUCE
S
Exploit
⚫ Dumping arbitrary memory:
⚫ Walk up stack until desired pointer is found.
⚫ printf( “%08x.%08x.%08x.%08x|%s|”)
⚫ Writing to arbitrary memory:
⚫ printf( “hello %n”, &temp) -- writes ‘6’ into
temp.
⚫ printf( “%08x.%08x.%08x.%08x.%n”)
FAST-NUCE
S
Platform Defenses
FAST-NUCE
S
Preventing hijacking attacks
1. Fix bugs:
⚫ Audit software
⚫Automated tools: Coverity,
⚫ Rewrite software in Prefast/Prefix.
a type safe languange (Java, ML)
⚫ Difficult for existing (legacy) code …
2. Concede overflow, but prevent code execution
3. Add runtime code to detect overflows exploits
⚫ Halt process when overflow exploit detected
⚫ StackGuard, LibSafe, …
FAST-NUCE
S
Marking memory as non-execute (W^X)
Prevent attack code execution by marking stack and
heap as non-executable
⚫ NX-bit on AMD Athlon 64, XD-bit on Intel P4Prescott
⚫ NX bit in every Page Table Entry (PTE)
⚫ Deployment:
⚫ Linux (via PaX project); OpenBSD
⚫ Windows: since XP SP2 (DEP: Data execution protection)
⚫ [Link] : /noexecute=OptIn or
⚫ Visual Studio: AlwaysOn
/NXCompat[:NO]
⚫ Limitations:
⚫ Some apps need executable heap (e.g. JITs).
⚫ Does not defend against `return-to-libc’ exploits
FAST-NUCE
S
Examples: DEP controls in
Windows
DEP terminating a program
FAST-NUCE
S
Attack:return to libc
⚫ Control hijacking without executing code
stack [Link]
args
ret-addr exec()
sfp printf()
local buf “/bin/sh”
FAST-NUCE
S
Response:
randomization
⚫ ASLR: (Address Space Layout Randomization)
⚫ Map shared libraries to rand location in process memory
⇒ Attacker cannot jump directly to exec function
⚫ Deployment: (/DynamicBase)
⚫ Windows Vista: 8 bits of randomness for DLLs
⚫ aligned to 64K page in a 16MB region ⇒ 256 choices
⚫ Linux (via PaX): 16 bits of randomness for libraries
⚫ More effective on64-bit architectures
⚫ Other randomization methods:
⚫ Sys-call randomization: randomize sys-call id’s
⚫ Instruction Set Randomization (ISR)
FAST-NUCE
S
ASLR Example
Booting twice loads libraries into different locations:
FAST-NUCE
S
Some attacks remain: JiT spraying
Idea:
1. Force Javascript JiT to fill heap with executable shellcode
2. then point SFP anywhere in spray area
NOP shellcod
slide e
p
hea
execute execute
enabled enabled
vtabl execute execute
e enabled enabled
FAST-NUCE
S
Run-Time Defenses
FAST-NUCE
S
Run time checking: StackGuard
⚫ Many run-time checking techniques …
⚫ we only discuss methods relevant to overflow protection
⚫ Solution 1: StackGuard
⚫ Run time tests for stack integrity.
⚫ Embed “canaries” in stack frames and verify their integrity prior
to function return.
Frame Frame
2 1 top
local canary local canary sfp ret str of
sfp ret str stac
k
FAST-NUCE
S
Canary
Types
⚫ Random canary:
⚫ Random string chosen at program startup.
⚫ Insert canary string (4-8 bytes) into every stack frame.
⚫ Verify canary before returning from function.
⚫ Exit program if canary [Link] potential exploit into DoS.
⚫ To corrupt, attacker must learn current random string.
⚫ Terminator canary: Canary = {0, newline, linefeed, EOF}
⚫ String functions will not copy beyond terminator.
⚫ Attacker cannot use string functions to corrupt stack.
⚫ Not used as often
FAST-NUCE
S
Acknowledgements
Material in this lecture are taken from the slides prepared by:
⚫ Prof. Dan Boneh (Standford)
FAST-NUCE
S
