Buffer overflow attacks can exploit vulnerabilities in C library functions like strcpy() that do not perform bounds checking on buffers. By passing in a string longer than the buffer size, an attacker can overwrite adjacent memory, such as the return address on the stack, allowing them to execute arbitrary code. Defenses include using type-safe languages, marking the stack as non-executable, static source code analysis, and runtime checks.

1. Buffer Overflow Attacks
1

2. 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
2

3. Basic stack exploit
o Main problem: no range checking in strcpy().
o Suppose *str is such that after strcpy stack looks like:
o When func() exits, the user will be given a shell !!
o Note: attack code runs in stack.
o To determine ret guess position of stack when func() is
called.
3

4. Some unsafe C lib functions
o strcpy (char *dest, const char *src)
o strcat (char *dest, const char *src)
o gets (char *s)
o scanf ( const char *format, … )
o printf (conts char *format, … )
4

5. Exploiting buffer overflows
Suppose web server calls func() with given URL.
Attacker can create a 200 byte URL to obtain shell
on web server.
Some complications:
o Program P should not contain the ‘0’ character.
o Overflow should not crash program before func()
exits.
Sample buffer overflow of this type:
o Overflow in MIME type field in MS Outlook.
5

6. Causing program to exec attack
code
o Stack smashing attack:
o Override return address in stack activation
record by overflowing a local
buffer variable.
o Function pointers: (used in attack on Linux)
o Overflowing buf will override function
pointer.
o Longjmp buffers: longjmp(pos) (used in
attack on Perl 5.003) 6

7. Finding buffer overflows
Hackers find buffer overflows as follows:
o Run web server on local machine.
o Issue requests with long tags.
o All long tags end with “$$$$$”.
o If web server crashes,
o search core dump for “$$$$$” to find
o overflow location.
o Some automated tools exist. (eEye Retina,
ISIC).
7

8. Preventing buf overflow attacks
o Main problem:
o strcpy(), strcat(), sprintf() have no range checking.
o “Safe” versions strncpy(), strncat() are misleading
o – strncpy() may leave buffer unterminated.
o – strncpy(), strncat() encourage off by 1 bugs.
o Defenses:
o Type safe languages (Java, ML). Legacy code?
o Mark stack as non-execute. Random stack location.
o Static source code analysis.
o Run time checking: StackGuard, Libsafe, SafeC,
(Purify).
o Black box testing (e.g. eEye Retina, ISIC ).
8

9. Marking stack as non-execute
o Basic stack exploit can be prevented by marking
o stack segment as non-executable or
o randomizing stack location.
o Code patches exist for Linux and Solaris.
o Problems:
o Does not block more general overflow exploits:
o – Overflow on heap: overflow buffer next to func
pointer.
o Some apps need executable stack (e.g. LISP
interpreters).
9

10. Static source code analysis
Statically check source to detect buffer overflows.
Several consulting companies.
Several tools exist:
o @stake (l0pht.com): SLINT (designed for UNIX)
o its4. Scans function calls.
o Wagner. Test constraint violations.
o Engler. Test trust inconsistency.
Find lots of bugs.
10

11. Recent Attacks
o RealPlayer, Helix Player, KM Player vulnerable to
attack.
o Exploit code released for Adobe Photoshop flaw.
News - Security - ZDNet
Australia_files
11