Stack buffer overflow

Stack buffer overflow

In software, a stack buffer overflow occurs when a program writes to a memory address on the program's call stack outside of the intended data structure; usually a fixed length buffer.cite web
last = Fithen
first = William L
coauthors = Seacord, Robert
publisher = US CERT
title = VT-MB. Violation of Memory Bounds
date = 2007-03-27
] cite book
last = Dowd
first = Mark
coauthors = McDonald, John; Schuh, Justin
title = The Art Of Software Security Assessment
publisher = Addison Wesley
date = November 2006
year = 2006
pages = 169-196
isbn = 0-321-44442-6
] Stack buffer overflow bugs are caused when a program writes more data to a buffer located on the stack than there was actually allocated for that buffer. This almost always results in corruption of adjacent data on the stack, and in cases where the overflow was triggered by mistake, will often cause the program to crash or operate incorrectly. This type of overflow is part of the more general class of programming bugs known as buffer overflows.

If the affected program is running with special privileges, or accepts data from untrusted network hosts (e.g. a webserver) then the bug is a potential security vulnerability. If the stack buffer is filled with data supplied from an untrusted user then that user can corrupt the stack in such a way as to inject executable code into the running program and take control of the process. This is one of the oldest and more reliable methods for black hats to gain unauthorized access to a computer.cite journal
last =Levy
first =Elias
authorlink = Elias Levy
title = Smashing the stack for fun and profit
journal =Phrack
issue =49
pages =14
date = 1996-11-08
url =
format =
] cite journal
last = Pincus
first = Jonathan
coauthors = Baker, Brandon
title = Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns
journal = IEEE Security & Privacy
volume = 2
issue = 4
pages =20–27
date =July-Aug. 2004
url =
doi =10.1109/MSP.2004.36
format = dead link|date=June 2008 – [ Scholar search]
] cite paper
author = Burebista
title = Stack Overflows
url =
format = PDF

Exploiting stack buffer overflows

The canonical method for exploiting a stack based buffer overflow is to overwrite the function return address with a pointer to attacker-controlled data (usually on the stack itself).cite conference
first = Louis
last = Bertrand
title = OpenBsd: Fix the Bugs, Secure the System
booktitle = MUSESS '02: McMaster University Software Engineering Symposium
year = 2002
] This is illustrated in the example below:

;An example with strcpyvoid foo (char *bar){ char c [12] ; strcpy(c, bar); // no bounds checking...} int main (int argc, char **argv){ foo(argv [1] ); }

This code takes an argument from the command line and copies it to a local stack variable c. This works fine for command line arguments smaller than 12 characters (as you can see in below). Any arguments larger than 11 characters long will result in corruption of the stack. (The maximum number of characters that is safe is one less than the size of the buffer here because in the C programming language strings are delimited by a zero byte character. A twelve-character input thus requires thirteen bytes to store, the input followed by the sentinel zero byte. The zero byte then ends up overwriting a memory location that's one byte beyond the end of the buffer.)

;The program stack in foo() with various inputs

(((TODO: The third picture above needs to be fixed. Strcpy always adds a NUL byte at the end)))

Notice in ), then the attacker could use this vulnerability to gain superuser privileges on the affected machine.

Platform related differences

A number of platforms have subtle differences in their implementation of the call stack that can affect the way a stack buffer overflow exploit will work. Some machine architectures store the top level return address of the call stack in a register. This means that any overwritten return address will not be used until a later unwinding of the call stack. Another example of a machine specific detail that can affect the choice of exploitation techniques is the fact that most RISC style machine architectures will not allow unaligned access to memory.cite paper
author = pr1
title = Exploiting SPARC Buffer Overflow vulnerabilities
url =
format =HTML
date =
] Combined with a fixed length for machine opcodes this machine limitation can make the jump to ESP technique almost impossible to implement (with the one exception being when the program actually contains the unlikely code to explicitly jump to the stack register).cite journal
author = Curious
title = Reverse engineering - PowerPC Cracking on Mac OS X with GDB
journal = Phrack
issue =63
pages =16
date = 2005-01-08
url =
] cite paper
author = Sovarel, Ana Nora
coauthor= Evans, David; Paul, Nathanael
title =Where’s the FEEB? The Effectiveness of Instruction Set Randomization
url =
format =HTML

tacks that grow up

Within the topic of stack buffer overflows an often discussed but rarely seen architecture is one in which the stack grows in the opposite direction. This change in architecture is frequently suggested as a solution to the stack buffer overflow problem because any overflow of a stack buffer that occurs within the same stack frame can not overwrite the return pointer. Further investigation of this claimed protection finds it to be a naïve solution at best. Any overflow that occurs in a buffer from a previous stack frame will still overwrite a return pointer and allow for malicious exploitation of the bug.cite journal
author = Zhodiac
title =HP-UX (PA-RISC 1.1) Overflows
journal =Phrack
volume =11
issue =58
pages =11
date =2001-12-28
url =
] For instance, in the example above, the return pointer for foo will not be overwritten because the overflow actually occurs within the stack frame for strcpy. However, because the buffer that overflows during the call to strcpy resides in a previous stack frame, the return pointer for strcpy will have a numerically higher memory address than the buffer. This means that instead of the return pointer for foo being overwritten, the return pointer for strcpy will be overwritten. At most this means that growing the stack in the opposite direction will change some details of how stack buffer overflows are exploitable, but it will not reduce significantly in the number of exploitable bugs.

Protection schemes

Over the years a number of schemes have been developed to inhibit malicious stack buffer overflow exploitation. These usually have taken one of two forms. The first method is to detect that a stack buffer overflow has occurred and thus prevent redirection of the instruction pointer to malicious code. The second attempts to prevent the execution of malicious code from the stack without directly detecting the stack buffer overflow.cite conference
first =Craig E.
last =Ward
title =C/C++ Buffer Overflows
booktitle =Unix Users Association of Southern California
date =2005-06-13
location = Orange County, California
url =
format = PDF

tack canaries

Stack canaries, so named because they operate as a canary in a coal mine so to speak, are used to detect a stack buffer overflow before execution of malicious code can occur. This method works by placing a small integer, the value of which is randomly chosen at program start, in memory just before the stack return pointer. Most buffer overflows overwrite memory from lower to higher memory addresses, so in order to overwrite the return pointer (and thus take control of the process) the canary value must also be overwritten. This value is checked to make sure it has not changed before a routine uses the return pointer on the stack. This technique can greatly increase the difficulty of exploiting a stack buffer overflow because it forces the attacker to gain control of the instruction pointer by some nontraditional means such as corrupting other important variables on the stack.

Nonexecutable stack

Another approach to preventing stack buffer overflow exploitation is to enforce memory policy on stack memory region to disallow execution from the stack. This means that in order to execute shellcode from the stack an attacker must either find a way to disable the execution protection from memory, or find a way to put his shellcode payload in a non-protected region of memory. This method is becoming more popular now that hardware support for the no-execute flag is available in most desktop processors.While this method definitely makes the canonical approach to stack buffer overflow exploitation FAIL it is not without its problems. First it is common to find ways to store shellcode in unprotected memory regions like the heap, and so very little need change in the way of exploitation.cite book
last =Foster
first =James C.
coauthors =Osipov, Vitaly; Bhalla, Nish; Heinen, Niels
title =Buffer Overflow Attacks: Detect, Exploit, Prevent
publisher =Syngress Publishing,Inc.
date =2005
location =United States of America
url =
isbn = 1-932266-67-4
] Even if this were not so there are other ways. The most damning is the so called return to libc method for shellcode creation. In this attack the malicious payload will load the stack not with shellcode, but with a proper call stack so that execution is vectored to a chain of standard library calls, usually with the effect of disabling memory execute protections and allowing shellcode to run as normal.cite journal
author = Nergal
title =The advanced return-into-lib(c) exploits: PaX case study
journal =Phrack
volume =11
issue =58
pages =4
date = 2001-12-28
url =
] This works because the execution never actually vectors to the stack itself. Still if used in conjunction with techniques like ASLR a nonexecutable stack can be somewhat resistant to return to libc attacks and thus can greatly improve the security of an application.

Notable examples

*The Morris worm spread in part by exploiting a stack buffer overflow in the Unix finger server. []
*The Witty worm spread by exploiting a stack buffer overflow in the Internet Security Systems BlackICE Desktop Agent. []
*The Slammer worm spread by exploiting a stack buffer overflow in Microsoft's SQL server. []
*The Blaster worm spread by exploiting a stack buffer overflow in Microsoft DCOM service
*The Twilight hack was made for the Wii by giving a lengthy character name for the horse ('Epona') in

ee also

*Stack overflow
*Call stack
*Buffer overflow
*Heap overflow
*Integer overflow
*Format string attack
*Vulnerability (computing)
*Exploit (computer security)
*Computer security


Wikimedia Foundation. 2010.