1. Anatomy of the Buffer Overflow
Adam Chapman
Stephen Hines
Tuesday April 1, 2003

2. Introduction
A buffer overflow is like trying to put ten pounds of sugar into a container that only holds five pounds. Once the container fills, the rest spills all over the counter and floor, making a mess.
Buffer overflows occur mainly because of C language libraries and partially because of poor programming practices.
The C language libraries are not going to change, but programming practices could undergo some improvement.

3. Framework The C language is a structured programming language.
Structured programming languages use the function call as their unit of organization.
While the designers of C were smart in designing a structured language, they also created the framework for buffer overflows.

4. The Stack
Each time a function is called, arguments to the function get copied to an area of memory called the stack.
You store things on the stack by pushing them on, and retrieve them by popping them off the stack.
All CPU architectures currently in use support the notion of a stack and have a special register (the stack pointer) and operations for pushing and popping.

5. The Stack
There is an operator that takes an address off the stack and copies it into the program counter,
The program counter is a register that determines the address of the next instruction to execute.
Calling a function always pushes the return address onto the stack.

6. Problems with the Stack
The problem with this design shows up within the called function.
Any variables defined within this function are also stored in space allocated on the stack.
For example, if a string, such as the name of a file to open, needs to be defined in the function, that number of bytes will be allocated on the stack.
The function can then use this memory, but it will automatically be unallocated after the function returns.
But C does no bounds checking when data is stored in this area, and this opens a hole for an attacker to exploit.

7. The Culprits
C library calls that copy data but do no bounds checking are the culprits (as well as the programmers who use these calls).
The strcat(), strcpy(), sprintf(), vsprintf(), bcopy(), gets(), and scanf() calls can be exploited because these functions don’t check to see if the buffer, allocated on the stack, will be large enough for the data copied into the buffer.
It is up to the programmer to either use a version that makes the check (such as strncpy() ) or to count the bytes of data before copying them onto the stack.

8. The Culprits
Given that there is a list of commonly abused subroutine calls, you might think it reasonable that all uses of these calls would be checked, and that the problem would be fixed forever.
Actually, it’s not quite as easy as that, and there are other ways of making similar mistakes
appending characters in a loop

9. The Culprits
In addition to subroutine calls, an attacker must also understand enough assembly in order to code the exploit itself.
In a buffer overflow exploit, code gets written on the stack, beyond the return address and function call arguments, and the return address gets modified so that it will point to the beginning (approximately) of the code.
Then, when the function call returns, the attacker’s code gets executed instead of normal program execution.

10. The Art
Getting the return address to point to the right location is one part of the “art” of buffer overflow exploits.
The other part covers the code itself.
Commonly, an offset argument lets the attacker try different locations merely by applying different values to adjust the position of the modified return address.

11. The Results
Among the information that is lost by the overflow is the ordered list of subroutines that had been called by the program up until the time when the attack occurred. In addition, the called arguments are also lost.
The intruder can overflow the buffer with a carefully crafted exploit script (a program written for malicious use) and then tells the program to treat the buffer as instructions and execute them.
The program does what the intruder wants, not what the programmer intended. In effect, the intruder becomes the programmer because his or her instructions are executed.

12. The Results
On Unix systems, a short program (which can be copied outright from existing exploits) executes a local program, most commonly the Unix command interpreter /bin/sh.
If the attacker already has local access, the result often is an interpreter run with superuser privileges.
If the attacker is remote, the TCP connection used to initiate the attack becomes connected to the shell program and often has superuser access. From here, the attacker can add a root account with their chosen password.

13. Buffer Overflow History
The Morris Worm (November 1988) was based on a buffer overflow in in the Unix fingerd daemon
Microsoft IIS 5.0
Recently had a buffer overflow with WebDAV
Code Red and variants were buffer overflows
WinXP Media Player and WinAmp both had buffer overflows from long ID3 tags in MP3s in December
OpenSSL had buffer overflows that were only patched last July (Modap, Scalper, Slapper worms)
Of course, the “King of buffer overflows” is most definitely Sendmail, which just had another one discovered and patched on March 29

14. Security Advisories
Security advisories including malicious buffer overflow exploit information are posted by CERT at
Buffer overflows are typically easy to patch, so usually within minutes or hours, a solution is available
System Administrators will monitor such sites carefully so as to keep systems and software patched and up to date
Unfortunately there is still the time gap between exploit discovery/release and the patching of systems, so these vulnerabilities are still problematic

15. Combating Buffer Overflows
Secure programming
This is difficult to implement, as legacy software and hardware may not be able to use secure library functions
Non-executable Runtime Stack
Implemented in OpenBSD 3.2
Static Detection
Only some buffer overflows can be detected statically. So this can’t solve all potential problems
Run-time Stack Inspection (StackGuard)
Can detect most common buffer overflows
Drawback is additional overhead, as well as the inability to detect heap-based overflows, or those related to function pointers

16. How StackGuard Works Standard Stack Layout StackGuard Stack Layout
0xFFFF
Stack
Growth
0x0000
Top of Stack
Return Address
Local Variables …
Buffer
Canary Word
Local Variables …

17. How StackGuard Works
Since most buffer overflows are caused by string manipulation, it is difficult to modify return addresses on the stack without modifying the “canary word” as well
This is because the stack counts from low to high for addressing buffers/strings
The main problem however is a stray pointer. Function pointers especially can be overwritten to point to other malicious code
Thus this method is effective for combating some buffer overflows, but cannot be used to eliminate them completely

18. Heap-based Buffer Overflows
In addition to stack-based attacks, it is also possible to abuse the heap in a similar manner
Famous example is Code Red worm
Basically the difference is that an overflowed buffer in the heap is used to modify another data structure’s members
Can also be used to modify function pointers in the heap, which are used in many Object Oriented programming languages to provide virtual function calls

19. Heap-based Exploit Protection
Luckily, these flaws are usually harder to exploit, due to potential varieties in memory layout after long run time of a program, but…
Non-executable heaps are not as popular or widespread as non-executable stacks
No simple solution to catch most of these types of exploits (like StackGuard’s canary word)

20. Conclusion
It is possible to avoid most buffer overflows through good programming practices
Tools are available that can help detect potential buffer overflow vulnerabilities
Security is a “must-have” and not a feature for programs today, since viruses/worms can be so devastating in a short amount of time

21. References
“Aleph One”. Smashing the stack for fun and profit. Phrack, 7(49), November 1996.
M. Conover and w00w00 Security Development. w00w00 on Heap Overflows. January 1999.
C. Cowan, C. Pu, D. Maier, et al. Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks. In Proceedings of the 7th USENIX Security Symposium, pages 63—78, San Antonio, TX, January 1998.
Rogers, Larry. Buffer Overflows – What Are They and What Can I Do About Them?.
D. Wagner, J. Foster, E. Brewer, and A. Aiken. A first step towards automated detection of buffer overrun vulnerabilities. In Network and Distributed System Security Symposium, San Diego, CA, February 2000.