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 400 300

20% of all vuln. 2005-2007: 10%

200 100 0 1995 1997 1999 2001 2003 2005

Source: NVD/CVE

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 0xC0000000

shared libraries brk Loaded from exec run Fme heap unused

0x40000000

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 char buf[128] SP
Dan Boneh

void func(char *str) { char buf[128]; strcpy(buf, str); do-something(buf); }

What are buer overows?

What if *str is 136 bytes long? Aier strcpy: void func(char *str) { char buf[128]; strcpy(buf, str); do-something(buf); argument: str return address stack frame pointer char buf[128] SP }

*str

Problem: no length checking in strcpy()

Dan Boneh

Basic stack exploit

Suppose *str is such that aier strcpy stack looks like: Program P: exec(/bin/sh)
When func() exits, the user gets shell ! Note: a5ack code P runs in stack. char buf[128]
(exact shell code by Aleph One)

high

Program P

return address

low
Dan Boneh

The NOP slide

Program P

high

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. Sample 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 Heap or stack

Overowing buf will override funcFon pointer.

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)
ptr data
FP1 FP2 FP3

vtable

method #1 method #2 method #3

Object T

NOP slide
data

shell code

Aier overow of buf :

buf[256] vtable ptr

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 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 s = 0x80 + 0x80 Can this be exploited? m = 0x80 + 0x80 c = 0 s = 0 m = 0

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

History
First exploit discovered in June 2000. Examples:

wu-ipd 2.* : Linux rpc.statd: IRIX telnetd: BSD chpass:

remote root remote root remote root local root

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 soiware
Automated tools: Coverity, Prefast/Prex.

Rewrite soiware 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
local buf
exec()
printf()
/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 Vista: 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, 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 execute enabled

shellcode

heap

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 dont provide full proof protecFon. Heap protecFon: PointGuard.
Some stack smashing a5acks leave canaries unchanged 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 excepaon handlers Stack Growth CANARY local string buers local non-buer variables copy of pointer args pointers, but no arrays
Dan Boneh

Canary protects ret-addr and excepFon handler frame

Evading /GS with excepFon handlers

When excepFon is thrown, dispatcher walks up excepFon list unFl handler is found (else use default handler) Aier overow: handler points to a5ackers code excepFon triggered control hijack
Main point: excepFon is triggered before canary is checked
0x next handler buf SEH frame 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 src buf sfp ret-addr top of stack
Dan Boneh

Libsafe strcpy

main

How robust is Libsafe?

low memory sfp ret-addr dest src buf sfp ret-addr high memory

Libsafe strcpy

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)
ptr data
FP1 FP2 FP3

vtable

method #1 method #2 method #3

Object T

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

buf[256] vtable
data

ptr

object T

Dan Boneh

Heap-based control hijacking

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

vtable

method #1 method #2 method #3

Object T

shell code vtable

data

Aier overow of buf we have:

buf[256] ptr

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

shellcode
Dan Boneh

data ptr

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