0% found this document useful (0 votes)
108 views

02 CTRL Hijacking PDF

The document discusses control hijacking attacks and buffer overflow vulnerabilities. It provides examples of buffer overflow attacks on Linux systems that allow executing arbitrary code by overwriting return addresses on the stack. Key points include: - Buffer overflows occur when a function copies a large input into a fixed-size buffer without bounds checking, overwriting adjacent memory. - An attacker can craft input that overwrites the return address on the stack to point to and execute shellcode injected on the stack. - A "NOP slide" of no-operation instructions makes the attack reliable by allowing the shellcode to execute regardless of exact stack state. - Many C library functions like strcpy are unsafe and have led to widespread buffer

Uploaded by

yosa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
108 views

02 CTRL Hijacking PDF

The document discusses control hijacking attacks and buffer overflow vulnerabilities. It provides examples of buffer overflow attacks on Linux systems that allow executing arbitrary code by overwriting return addresses on the stack. Key points include: - Buffer overflows occur when a function copies a large input into a fixed-size buffer without bounds checking, overwriting adjacent memory. - An attacker can craft input that overwrites the return address on the stack to point to and execute shellcode injected on the stack. - A "NOP slide" of no-operation instructions makes the attack reliable by allowing the shellcode to execute regardless of exact stack state. - Many C library functions like strcpy are unsafe and have led to widespread buffer

Uploaded by

yosa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 57

Control

Hijacking

Basic Control
Hijacking A5acks
Dan Boneh

Control hijacking a5acks


A5ackers goal:

Take over target machine (e.g. web server)


Execute arbitrary code on target by
hijacking applicaFon control ow
Examples.

Buer overow a5acks


Integer overow a5acks
Format string vulnerabiliFes
Dan Boneh

Example 1: buer overows


Extremely common bug in C/C++ programs.
First major exploit: 1988 Internet Worm. ngerd.

600
500

20% of all vuln.

400
300

200
100
0

Source: NVD/CVE
1995 1997 1999 2001 2003

2005

Dan Boneh

What is needed
Understanding C funcFons, the stack, and the heap.
Know how system calls are made
The exec() system call
A5acker 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:
Li5le endian vs. big endian (x86 vs. Motorola)
Stack Frame structure (Unix vs. Windows)
Dan Boneh

Linux process memory layout


%esp

user stack

shared libraries
brk
Loaded
from exec

0xC0000000

0x40000000

run Fme heap


unused

0x08048000
0

Dan Boneh

Stack Frame
high

arguments
return address
stack frame pointer
excepFon handlers
local variables
SP

callee saved registers

Stack
Growth
low
Dan Boneh

What are buer overows?


Suppose a web server contains a funcFon:
When func() is called stack looks like:
argument: str
return address
stack frame pointer

void func(char *str) {


char buf[128];
strcpy(buf, str);
do-something(buf);
}

char buf[128]
SP

Dan Boneh

What are buer overows?


What if *str is 136 bytes long?
Afer strcpy:

void func(char *str) {


char buf[128];
strcpy(buf, str);
do-something(buf);

*str

argument: str
return address
stack frame pointer
char buf[128]

SP

Problem:
no length checking in strcpy()

Dan Boneh

Basic stack exploit


Suppose *str is such that
afer strcpy stack looks like:

high

Program P

Program P: exec(/bin/sh)

(exact shell code by Aleph One)

return address


When func() exits, the user gets shell !
Note: a5ack code P runs in stack.

char buf[128]
low
Dan Boneh

The NOP slide

high

Program P

Problem: how does a5acker


determine ret-address?

SoluFon: NOP slide
Guess approximate stack state
when func() is called
Insert many NOPs before program P:
nop , xor eax,eax , inc ax

NOP Slide

return address

char buf[128]
low
Dan Boneh

Details and examples


Some complicaFons:
Program P should not contain the \0 character.
Overow should not crash program before func() exists.
(in)Famous remote stack smashing overows:
(2007) Overow in Windows animated cursors (ANI). LoadAniIcon()
(2005) Overow in Symantec Virus DetecFon
test.GetPrivateProfileString "file", [long string]
Dan Boneh

Many unsafe libc funcFons


strcpy (char *dest, const char *src)
strcat (char *dest, const char *src)
gets (char *s)
scanf ( const char *format, ) and many more.
Safe libc versions strncpy(), strncat() are misleading
e.g. strncpy() may leave string unterminated.
Windows C run Fme (CRT):
strcpy_s (*dest, DestSize, *src): ensures proper terminaFon
Dan Boneh

Buer overow opportuniFes


ExcepFon handlers: (Windows SEH a5acks)
Overwrite the address of an excepFon handler in stack frame.
FuncFon pointers: (e.g. PHP 4.0.2, MS MediaPlayer Bitmaps)
buf[128]

FuncPtr

Overowing buf will override funcFon pointer.

Heap
or
stack

Longjmp buers: longjmp(pos) (e.g. Perl 5.003)


Overowing buf next to pos overrides value of pos.

Dan Boneh

CorrupFng method pointers


Compiler generated funcFon pointers (e.g. C++ code)
FP1
FP2
FP3

ptr

vtable

data

method #1
method #2
method #3

NOP
slide

Object T

shell
code

vtable

data

buf[256]

ptr

Afer overow of buf :

object T

Dan Boneh

Finding buer overows


To nd overow:
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 nd overow locaFon

Construct exploit (not easy given latest defenses)
Dan Boneh

Control Hijacking

More Control
Hijacking A5acks
Dan Boneh

More Hijacking OpportuniFes


Integer overows: (e.g. MS DirectX MIDI Lib)
Double free: double free space on heap
Can cause memory mgr to write data to specic locaFon
Examples: CVS server
Use after free: using memory after it is freed
Format string vulnerabilities
Dan Boneh

Integer Overows (see Phrack 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 = 0x80 + 0x80

s = 0

m = 0x80 + 0x80

m = 0


Can this be exploited?

Dan Boneh

An example
void func( char *buf1, *buf2, unsigned int len1, len2) {
char temp[256];
if (len1 + len2 > 256) {return -1}
// length check
memcpy(temp, buf1, len1);
// cat buffers
memcpy(temp+len1, buf2, len2);
do-something(temp);
// do stuff
}

What if len1 = 0x80, len2 = 0x80 ?


len1+len2 = 0
Second memcpy() will overow heap !!

Dan Boneh

Integer overow exploit stats


140
120
100
80
60
40
20
0

1996

1998

2000

2002

2004

2006

Source: NVD/CVE

Dan Boneh

Format string bugs

Dan Boneh

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
Correct form: fprintf( stdout, %s, user);
Dan Boneh

Vulnerable funcFons
Any funcFon using a format string.

PrinFng:
prin{, fprin{, sprin{,
vprin{, vfprin{, vsprin{,

Logging:
syslog, err, warn
Dan Boneh

Exploit
Dumping arbitrary memory:
Walk up stack unFl desired pointer is found.
prin{( %08x.%08x.%08x.%08x|%s|)
WriFng to arbitrary memory:
prin{( hello %n, &temp) -- writes 6 into temp.
prin{( %08x.%08x.%08x.%08x.%n)
Dan Boneh

Control Hijacking

Pla{orm Defenses

Dan Boneh

PrevenFng hijacking a5acks


1. Fix bugs:

Audit sofware
Automated tools: Coverity, Prefast/Prex.

Rewrite sofware in a type safe languange (Java, ML)


Dicult for exisFng (legacy) code

2. Concede overow, but prevent code execuFon


3. Add runFme code to detect overows exploits

Halt process when overow exploit detected


StackGuard, LibSafe,

Dan Boneh

Marking memory as non-execute (W^X)


Prevent a5ack code execuFon by marking stack and heap as non-executable
NX-bit on AMD Athlon 64,

XD-bit on Intel P4 Prescott

NX bit in every Page Table Entry (PTE)


Deployment:
Linux (via PaX project); OpenBSD
Windows: since XP SP2 (DEP)
Visual Studio: /NXCompat[:NO]

LimitaFons:
Some apps need executable heap (e.g. JITs).
Does not defend against `Return Oriented Programming exploits
Dan Boneh

Examples: DEP controls in Windows

DEP terminaFng a program


Dan Boneh

A5ack: Return Oriented Programming (ROP)


Control hijacking without execuFng code
stack
libc.so
args
ret-addr
sfp

exec()
printf()

local buf

/bin/sh

Dan Boneh

Response: randomizaFon

ASLR: (Address Space Layout RandomizaFon)

Map shared libraries to rand locaFon in process memory


A5acker cannot jump directly to exec funcFon
Deployment: (/DynamicBase)
Windows 7: 8 bits of randomness for DLLs
aligned to 64K page in a 16MB region 256 choices
Windows 8: 24 bits of randomness on 64-bit processors

Other randomizaFon methods:


Sys-call randomizaFon: randomize sys-call ids
InstrucFon Set RandomizaFon (ISR)

Dan Boneh

ASLR Example
Booting twice loads libraries into different locations:

Note: everything in process memory must be randomized



stack, heap, shared libs, base image
Win 8 Force ASLR: ensures all loaded modules use ASLR

Dan Boneh

More a5acks : JiT spraying


Idea:

1. Force Javascript JiT to ll heap with


executable shellcode

2. then point SFP anywhere in spray area


NOP slide
execute enabled

execute enabled

execute enabled

heap

execute enabled

shellcode

vtable

Dan Boneh

Control Hijacking

Run-Fme Defenses

Dan Boneh

Run Fme checking: StackGuard


Many run-Fme checking techniques
we only discuss methods relevant to overow protecFon
SoluFon 1: StackGuard
Run Fme tests for stack integrity.
Embed canaries in stack frames and verify their integrity
prior to funcFon return.
local

Frame 2
canary sfp ret str

Frame 1
local

canary

sfp ret str

top
of
stack
Dan Boneh

Canary Types
Random canary:
Random string chosen at program startup.
Insert canary string into every stack frame.
Verify canary before returning from funcFon.
Exit program if canary changed. Turns potenFal exploit into DoS.

To corrupt, a5acker must learn current random string.

Terminator canary: Canary = {0, newline, linefeed, EOF}


String funcFons will not copy beyond terminator.
A5acker cannot use string funcFons to corrupt stack.
Dan Boneh

StackGuard (Cont.)
StackGuard implemented as a GCC patch

Program must be recompiled

Minimal performance eects: 8% for Apache


Note: Canaries do not provide full protecFon

Some stack smashing a5acks leave canaries unchanged

Heap protecFon: PointGuard

Protects funcFon pointers and setjmp buers by encrypFng them:


e.g. XOR with random cookie
Less eecFve, more noFceable performance eects
Dan Boneh

StackGuard enhancements: ProPolice


ProPolice (IBM) - gcc 3.4.1. (-fstack-protector)
Rearrange stack layout to prevent ptr overow.

args
String
Growth
ret addr
Protects pointer args and local
pointers from a buer overow
SFP
CANARY
local string buers
Stack
pointers, but no arrays
Growth
local non-buer variables
copy of pointer args

Dan Boneh

MS Visual Studio /GS [since 2003]


Compiler /GS opFon:
CombinaFon of ProPolice and Random canary.
If cookie mismatch, default behavior is to call _exit(3)

FuncFon
prolog:
FuncFon epilog:
sub esp, 8 // allocate 8 bytes for cookie
mov eax, DWORD PTR ___security_cookie
xor eax, esp // xor cookie with current esp
mov DWORD PTR [esp+8], eax // save in stack

mov ecx, DWORD PTR [esp+8]


xor ecx, esp
call @__security_check_cookie@4
add esp, 8

Enhanced /GS in Visual Studio 2010:


/GS protecFon added to all funcFons, unless can be proven unnecessary
Dan Boneh

/GS stack frame


String
Growth

args
ret addr
SFP

Canary protects ret-addr and


excepFon handler frame

excepaon handlers
Stack
Growth

CANARY
local string buers
local non-buer variables
copy of pointer args

pointers, but no arrays


Dan Boneh

Evading /GS with excepFon handlers


When excepFon is thrown, dispatcher walks up excepFon list
unFl handler is found (else use default handler)
Afer overow: handler points to a5ackers code
excepFon triggered control hijack
Main point: excepFon is triggered before canary is checked
0x

SEH frame
next

handler

buf

ptr to
next
next handler
a5ack code

SEH frame
next

handler

high
mem
Dan Boneh

Defenses: SAFESEH and SEHOP


/SAFESEH: linker ag
Linker produces a binary with a table of safe excepFon handlers
System will not jump to excepFon handler not on list

/SEHOP: pla{orm defense (since win vista SP1)


ObservaFon: SEH a5acks typically corrupt the next entry in SEH list.
SEHOP: add a dummy record at top of SEH list
When excepFon occurs, dispatcher walks up list and veries dummy
record is there. If not, terminates process.
Dan Boneh

Summary: Canaries are not full proof


Canaries are an important defense tool, but do not prevent all
control hijacking a5acks:
Heap-based a5acks sFll possible
Integer overow a5acks sFll possible
/GS by itself does not prevent ExcepFon Handling a5acks

(also need SAFESEH and SEHOP)

Dan Boneh

What if cant recompile: Libsafe


SoluFon 2: Libsafe (Avaya Labs)
Dynamically loaded library (no need to recompile app.)
Intercepts calls to strcpy (dest, src)
Validates sucient space in current stack frame:
|frame-pointer dest| > strlen(src)
If so, does strcpy. Otherwise, terminates applicaFon
sfp ret-addr

dest

Libsafe strcpy

src

buf

sfp ret-addr

main

top
of
stack
Dan Boneh

How robust is Libsafe?


low
memory

sfp ret-addr

dest

Libsafe strcpy

src

buf

sfp ret-addr

high
memory

main

strcpy() can overwrite a pointer between buf and sfp.

Dan Boneh

More methods
StackShield
At funcFon prologue, copy return address RET and SFP to
safe locaFon (beginning of data segment)
Upon return, check that RET and SFP is equal to copy.
Implemented as assembler le processor (GCC)
Control Flow Integrity (CFI)
A combinaFon of staFc and dynamic checking
StaFcally determine program control ow
Dynamically enforce control ow integrity
Dan Boneh

Control Hijacking

Advanced
Hijacking A5acks
Dan Boneh

Heap Spray A5acks


A reliable method for exploiFng heap overows

Dan Boneh

Heap-based control hijacking


Compiler generated funcFon pointers (e.g. C++ code)
FP1
FP2
FP3

ptr
data

vtable

method #1
method #2
method #3

Object T

vtable

data

buf[256]

ptr

Suppose vtable is on the heap next to a string object:

object T

Dan Boneh

Heap-based control hijacking


Compiler generated funcFon pointers (e.g. C++ code)
FP1
FP2
FP3

ptr

vtable

data

method #1
method #2
method #3

Object T

shell
code
vtable

data

buf[256]

ptr

Afer overow of buf we have:

object T

Dan Boneh

A reliable exploit?

<SCRIPT language="text/javascript">

shellcode = unescape("%u4343%u4343%...");
overow-string = unescape(%u2332%u4276%...);

cause-overow( overow-string ); // overow buf[ ]


</SCRIPT>

Problem: a5acker does not know where browser


places shellcode on the heap
buf[256]

vtable

data
ptr

???

shellcode
Dan Boneh

Heap Spraying [SkyLined 2004]


Idea:

1. use Javascript to spray heap




with shellcode (and NOP slides)
2. then point vtable ptr anywhere in spray area
NOP slide

shellcode

heap

vtable
heap spray area
Dan Boneh

Javascript heap spraying


var nop = unescape(%u9090%u9090)
while (nop.length < 0x100000) nop += nop
var shellcode = unescape("%u4343%u4343%...");
var x = new Array ()
for (i=0; i<1000; i++) {
x[i] = nop + shellcode;
}

PoinFng func-ptr almost anywhere in heap will


cause shellcode to execute.
Dan Boneh

Vulnerable buer placement


Placing vulnerable buf[256] next to object O:
By sequence of Javascript allocaFons and frees
make heap look as follows:
free blocks
heap
object O

Allocate vuln. buer in Javascript and cause overow


Successfully used against a Safari PCRE overow [DHM08]
Dan Boneh

Many heap spray exploits


[RLZ08]

Improvements: Heap Feng Shui [S07]


Reliable heap exploits on IE without spraying
Gives a5acker full control of IE heap from Javascript

Dan Boneh

(parFal) Defenses
Protect heap funcFon pointers (e.g. PointGuard)
Be5er browser architecture:

Store JavaScript strings in a separate heap from browser heap

OpenBSD heap overow protecFon:


prevents
cross-page
overows

non-writable pages
Nozzle [RLZ08] : detect sprays by prevalence of code on heap
Dan Boneh

References on heap spraying


[1] Heap Feng Shui in Javascript,
by A. SoFrov, Blackhat Europe 2007

[2] Engineering Heap Overow Exploits with JavaScript
M. Daniel, J. Honoro, and C. Miller, WooT 2008

[3] Nozzle: A Defense Against Heap-spraying Code Injecaon Aiacks,
by P. Ratanaworabhan, B. Livshits, and B. Zorn

[4] Interpreter Exploitaaon: Pointer inference and JiT spraying,
by Dion Blazakis
Dan Boneh

End of Segment

Dan Boneh

You might also like