This document discusses control hijacking attacks that aim to take control of a victim's machine by exploiting vulnerabilities in programs. It covers different types of attacks like buffer overflow attacks, integer overflow attacks, and format string vulnerabilities. These attacks work by injecting attack code or parameters to abuse vulnerabilities and modify memory to redirect the control flow. The document also discusses defenses like choosing programming languages with strong typing and automatic checks, auditing software, and adding runtime checks using techniques like stack canaries to detect exploits and prevent code execution.

1. Control Hijacking Attacks

2. Table of Contents
• Attacker’s Intentions
• Buffer Overflow Attacks
 Basic Stack Exploit
 Heap based buffer overflow attack
 Defense Against Buffer Overflow Attack
 Integer Overflow Attack
 Format String Attack
 Prevention of Control Hijacking Attacks
 Runtime Checking: Stackguard

3. Attacker’s Intentions
Take control of the victim’s machine
 Hijack the execution flow of a running program
 Execute arbitrary code
Requirements
 Inject attack code or attack parameters
 Abuse vulnerability and modify memory such that control flow is redirected

4. Attacker’s Intentions (Contd)
Examples
 Buffer Overflow attack
 Integer overflow attack
 Format string vulnerabilities
• What is needed by attacker?
 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:

5. Buffer Overflow Attack
• Result from mistakes done while writing code
 Coding flaws because of
• unfamiliarity with language
• Ignorance about security issues
• unwillingness to take extra effort
• Often related to particular programming language
• Buffer overflows
 mostly relevant for C / C++ programs
 not in languages with automatic memory management

6. Buffer Overflow Attack (Contd.)
• dynamic bounds checks (e.g., Java)
• automatic resizing of buffers (e.g., Perl)
• One of the most used attack techniques
• What is needed to understand buffer overflow attack?
 Understanding C functions and the stack
 Some familiarity with machine code
 Know how systems calls are made
 The exec() system call

7. Stack Frame
Parameters
Return address
Stack Frame Pointer
Local variables
SP
Stack
Growth

8. What are buffer overflows?
• Suppose a web server contains a function:
void func (char *str) {
char buf [128];
strcpy (buf, str);
do-something (buf);
}
• When the function is invoked the stack looks like:
• What if *str is 136 bytes long? After strcpy:
strret-addrsfpbuf
Top
of
stack
str
Top
of
stack
*str ret

9. Exploiting buffer overflows
• Suppose web server calls func() with given URL.
 Attacker sends a 200 byte URL. Gets shell on web server
• Some complications:
 Program P should not contain the ‘0’ character.
 Overflow should not crash program before func() exists.
• Sample remote buffer overflows of this type:
 (2005) Overflow in MIME type field in MS Outlook.
 (2005) Overflow in Symantec Virus Detection
Set test = CreateObject ("Symantec.SymVAFileQuery.1")
test.GetPrivateProfileString "file", [long string]

10. Basic stack exploit
• Problem: no range checking in strcpy().
• Suppose *str is such that after strcpy stack looks like:
• When func() exits, the user will be given a shell !
• Note: attack code runs in stack.
• To determine ret guess position of stack when func() is called
Top
of
stack*str ret Code for P
Program P: exec( “/bin/sh” )
(exact shell code by Aleph One)

11. Stack-based attacks: many variants
• Return address clobbering
• Overwriting function pointers (e.g. PHP 4.0.2, MediaPlayer, BMP).
• Overwriting exception-handler pointers (C++).
 Need to cause an exception afterwards
• Overwriting longjmp buffers (e.g. Perl 5.003)
 Mechanism for error handling in C
• Overwriting saved frame pointer (SFP)
 Off-by-one error is enough: one byte buffer overflow!
 First return (leave) sets SP to overwritten SFP.
 Second return (ret) jumps to fake top of stack
Heap
or
stack
buf[128] FuncPtr

12. Control Hijacking Opportunities
• Stack smashing attack:
 Override return address in stack activation record by overflowing a local buffer
variable.
• Function pointers: (e.g. PHP 4.0.2, MS Media Player Bitmaps)
 Overflowing buf will override function pointer.
• Longjmp buffers: longjmp (pos) (e.g. Perl 5.003)
 Overflowing buf next to pos overrides value of pos.
Heap
or
stackbuf[128] FuncPtr

13. Heap-based control hijacking
• Compiler generated function pointers (e.g. C++ code)
• Suppose vtable is on the heap next to a string object:
ptr
data
Object T
FP1
FP2
FP3
vtable
method #1
method #2
method #3
ptr
buf[256]
data
object T
vtable

14. Heap-based control hijacking
• Compiler generated function pointers (e.g. C++ code)
• After overflow of buf we have:
ptr
data
Object T
FP1
FP2
FP3
vtable
method #1
method #2
method #3
ptr
buf[256]
data
object T
vtable
shell
code

15. Defense Against Buffer Overflow Attack
• Programming language choice is crucial
• The language
 should be strongly typed
 Should do automatic bound checks.
 Should do automatic memory management.

16. Integer Overflow Attack
• Integer overflows: e.g. MS DirectX MIDI Lib, Phrack60
void func(int a, char v)
{
char buf[128];
init(buf);
buf[a] = v;
}
• Problem: a can point to `ret-addr’ on stack.
• Double free: double free space on heap.
 Can cause mem mgr to write data to specific location
 Examples: CVS server

17. An Example
void func( char *buf1, *buf2, unsigned int len1, len2) {
char temp[256];
if (len1 + len2 > 256) {return -1} //lengthcheck
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

18. Format String Attack
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:
int func(char *user) {
fprintf( stdout, “%s”, user);
}

19. Vulnerable functions
• Any function using a format string.
• Printing:
 printf, fprintf, sprintf, …
 vprintf, vfprintf, vsprintf, …
• Logging:
syslog, err, warn

20. 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”)

21. Control Hijacking
Preventing hijacking attacks
• Fix bugs:
 Audit software
 Automated tools: Coverity, Prefast/ Prefix.
 Rewrite software in a type safe language (Java, ML)
• Difficult for existing (legacy) code ...
• Concede overflow, but prevent code execution
• Add runtime code to detect overflows exploits
 Halt process when overflow exploit detected
 StackGuard, LibSafe, ...

22. Run time checking: StackGuard
• StackGuard
 Run time tests for stack integrity.
 Embed “canaries” in stack frames and verify their
 integrity prior to function return.
• Canary Types
 Random canary:
• Choose random string at program startup.
• Insert canary string into every stack frame.
• Verify canary before returning from function.
• To corrupt random canary, attacker must learn current random string.

23. Canary (Contd)
• Terminator canary:
 Canary = 0, newline, linefeed, EOF
• String functions will not copy beyond terminator.
• Attacker cannot use string functions to corrupt stack.
• StackGuard implemented as a GCC patch.
 Program must be recompiled.
• Minimal performance effects: 8% for Apache.
• Note: Canaries don’t offer fullproof protection.
 Some stack smashing attacks leave canaries unchanged
• Heap protection: PointGuard
 Protects function pointers and setjmp buffers by encrypting them: XOR
with random cookie
 Less effective, more noticeable performance effects
• .