【嵌入式安全扫盲一】Stack buffer overflow

蔚落 2022-06-10 09:50 151阅读 0赞

出处：[https://en.wikipedia.org/wiki/Stack\_buffer\_overflow][https_en.wikipedia.org_wiki_Stack_buffer_overflow]

# Stack buffer overflow #

From Wikipedia, the free encyclopedia

For other uses, see [Stack overflow (disambiguation)][Stack overflow _disambiguation].

In software, a **stack buffer overflow** or **stack buffer overrun** occurs when a program writes to a [memory][] address on the program's [call stack][] outside of the intended data structure, which is usually a fixed-length buffer.[\[1\]][1][\[2\]][2] Stack buffer overflow bugs are caused when a program writes more data to a buffer located on the stack than what is 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. Stack buffer overflow is a type of the more general programming malfunction known as [buffer overflow][] (or buffer overrun).[\[1\]][1] Overfilling a buffer on the stack is more likely to derail program execution than overfilling a buffer on the heap because the stack contains the return addresses for all active function calls.

Stack buffer overflow can be caused deliberately as part of an attack known as **stack smashing**. 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 [attackers][] to gain unauthorized access to a computer.[\[3\]][3][\[4\]][4][\[5\]][5]

## Contents ##

\[hide\]

*  [1Exploiting stack buffer overflows][]
 *  [2Platform related differences][]
    
     *  [2.1Stacks that grow up][]
 *  [3Protection schemes][]
    
     *  [3.1Stack canaries][]
     *  [3.2Nonexecutable stack][]
     *  [3.3Randomization][]
 *  [4Notable examples][]
 *  [5See also][]
 *  [6References][]

## Exploiting stack buffer overflows\[[edit][]\] ##

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).[\[3\]][3][\[6\]][6] This is illustrated with `strcpy()` in the following example:

#include <string.h>
    
    void foo (char *bar)
    {
          
       char  c[12];
    
       strcpy(c, bar);  // no bounds checking
    }
    
    int main (int argc, char **argv)
    {
          
       foo(argv[1]);
    
       return 0;
    }

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 [figure B][]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 terminated 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:

![20170816112322927][]  
The attacker can also modify internal variable values to exploit some bugs. With this example:Notice in [figure C][] above, when an argument larger than 11 bytes is supplied on the command line `foo()` overwrites local stack data, the saved frame pointer, and most importantly, the return address. When `foo()` returns it pops the return address off the stack and jumps to that address (i.e. starts executing instructions from that address). Thus, the attacker has overwritten the return address with a pointer to the stack buffer `char c[12]`, which now contains attacker-supplied data. In an actual stack buffer overflow exploit the string of "A"'s would instead be[shellcode][] suitable to the platform and desired function. If this program had special privileges (e.g. the [SUID][] bit set to run as the [superuser][]), then the attacker could use this vulnerability to gain superuser privileges on the affected machine.[\[3\]][3]

#include <string.h>
    #include <stdio.h>
    
    void foo (char *bar)
    {
          
       float My_Float = 10.5; // Addr = 0x0023FF4C
       char  c[28];           // Addr = 0x0023FF30
    
       // Will print 10.500000
       printf("My Float value = %f\n", My_Float);
    
        /* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           Memory map:
           @ : c allocated memory
           # : My_Float allocated memory
    
               *c                      *My_Float
           0x0023FF30                  0x0023FF4C
               |                           |
               @@@@@@@@@@@@@@@@@@@@@@@@@@@@#####
          foo("my string is too long !!!!! XXXXX");
    
       memcpy will put 0x1010C042 (little endian) in My_Float value.
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
    
       memcpy(c, bar, strlen(bar));  // no bounds checking...
    
       // Will print 96.031372
       printf("My Float value = %f\n", My_Float);
    }
    
    int main (int argc, char **argv)
    {
          
       foo("my string is too long !!!!! \x10\x10\xc0\x42");
       return 0;
    }

## Platform related differences\[[edit][edit 1]\] ##

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.[\[7\]][7] 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).[\[8\]][8][\[9\]][9]

### Stacks that grow up\[[edit][edit 2]\] ###

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 naive 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.[\[10\]][10] 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 the number of exploitable bugs.

## Protection schemes\[[edit][edit 3]\] ##

Main article: [Buffer overflow protection][]

Over the years a number of [control-flow integrity][] schemes have been developed to inhibit malicious stack buffer overflow exploitation. These may usually be classified into three categories:

*  Detect that a stack buffer overflow has occurred and thus prevent redirection of the instruction pointer to malicious code.
 *  Prevent the execution of malicious code from the stack without directly detecting the stack buffer overflow.
 *  Randomize the memory space such that finding executable code becomes unreliable.

### Stack canaries\[[edit][edit 4]\] ###

Further information: [Canary value][]

Stack canaries, named for their analogy to a [canary in a coal mine][], 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.[\[2\]][2] 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 non-traditional means such as corrupting other important variables on the stack.[\[2\]][2]

### Nonexecutable stack\[[edit][edit 5]\] ###

Main article: [Data Execution Prevention][]

Another approach to preventing stack buffer overflow exploitation is to enforce a memory policy on the stack memory region that disallows execution from the stack ([W^X][W_X], "Write XOR Execute"). 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 her/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.[\[11\]][11]

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.[\[12\]][12] This works because the execution never actually vectors to the stack itself.

A variant of return-to-libc is [return-oriented programming][], which sets up a series of return addresses, each of which executes a small sequence of cherry-picked machine instructions within the existing program code or system libraries, sequence which ends with a return. These so-called *gadgets* each accomplish some simple register manipulation or similar execution before returning, and stringing them together achieves the attacker's ends. It is even possible to use "returnless" return-oriented programming by exploiting instructions or groups of instructions that behave much like a return instruction.[\[13\]][13]

### Randomization\[[edit][edit 6]\] ###

Instead of separating the code from the data another mitigation technique is to introduce randomization to the memory space of the executing program. Since the attacker needs to determine where executable code that can be used resides, either an executable payload is provided (with an executable stack) or one is constructed using code reuse such as in ret2libc or ROP (Return Oriented Programming) randomizing the memory layout will as a concept prevent the attacker from knowing where any code is. However, implementations typically will not randomize everything; usually the executable itself is loaded at a fixed address and hence even when [ASLR][] (Address Space Layout Randomization) is combined with a nonexecutable stack the attacker can use this fixed region of memory. Therefore, all programs should be compiled with [PIE][] (position-independent executables) such that even this region of memory is randomized. The entropy of the randomization is different from implementation to implementation and a low enough entropy can in itself be a problem in terms of brute forcing the memory space that is randomized.

## Notable examples\[[edit][edit 7]\] ##

*  The [Morris worm][] spread in part by exploiting a stack buffer overflow in the [Unix][] [finger][] server.[\[1\]][1 1]
 *  The [Witty worm][] spread by exploiting a stack buffer overflow in the [Internet Security Systems][] BlackICE Desktop Agent.[\[2\]][2 1]
 *  The [Slammer worm][] spread by exploiting a stack buffer overflow in [Microsoft][]'s SQL server.[\[3\]][3 1]
 *  The [Blaster worm][] spread by exploiting a stack buffer overflow in Microsoft [DCOM][] service.
 *  There are a couple of examples the [Wii][] allowing arbitrary code to be run on an unmodified system. The "Twilight hack" which involves giving a lengthy name to the main character's horse in*[The Legend of Zelda: Twilight Princess][The Legend of Zelda_ Twilight Princess]*, and "Smash Stack" for *[Super Smash Bros. Brawl][]* which involves using an SD card to load a specially prepared file into the in-game level editor. Though both can be used to execute any arbitrary code, the latter is often used to simply reload *Brawl* itself with [modifications][] applied.

## See also\[[edit][edit 8]\] ##

*  [![icon][]][icon 1][Computer security portal][]

*  [Address space layout randomization][]
 *  [Buffer overflow][buffer overflow]
 *  [Call stack][call stack]
 *  [Computer security][]
 *  [ExecShield][]
 *  [Executable space protection][]
 *  [Exploit (computer security)][Exploit _computer security]
 *  [Format string attack][]
 *  [grsecurity][]
 *  [Heap overflow][]
 *  [Integer overflow][]
 *  [NX bit][]
 *  [PaX][]
 *  [Return-oriented programming][return-oriented programming]
 *  [Security-Enhanced Linux][]
 *  [Stack overflow][]
 *  [Storage violation][]
 *  [Vulnerability (computing)][Vulnerability _computing]

## References\[[edit][edit 9]\] ##

1.  ^ [Jump up to:***a***][Jump up to_a] [***b***][b] Fithen, William L.; Seacord, Robert (2007-03-27).["VT-MB. Violation of Memory Bounds"][VT-MB. Violation of Memory Bounds]. [US CERT][].
2.  ^ [Jump up to:***a***][Jump up to_a 1] [***b***][b 1] [***c***][c] Dowd, Mark; McDonald, John; Schuh, Justin (November 2006). *The Art Of Software Security Assessment*.[Addison Wesley][]. pp. 169–196. [ISBN][] [0-321-44442-6][].
3.  ^ [Jump up to:***a***][Jump up to_a 2] [***b***][b 2] [***c***][c 1] [Levy, Elias][Levy_ Elias] (1996-11-08). ["Smashing The Stack for Fun and Profit"][Smashing The Stack for Fun and Profit]. *[Phrack][]*. **7** (49): 14.
4.  **[Jump up^][Jump up]** Pincus, J.; Baker, B. (July–August 2004). ["Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns"][Beyond Stack Smashing_ Recent Advances in Exploiting Buffer Overruns] (PDF). *IEEE Security and Privacy Magazine*. **2**(4): 20–27. [doi][]:[10.1109/MSP.2004.36][10.1109_MSP.2004.36].
5.  **[Jump up^][Jump up 1]** Burebista. ["Stack Overflows"][Stack Overflows] (PDF). Archived from [the original][] (PDF) on September 28, 2007. (dead link)
6.  **[Jump up^][Jump up 2]** Bertrand, Louis (2002). ["OpenBSD: Fix the Bugs, Secure the System"][OpenBSD_ Fix the Bugs_ Secure the System]. *MUSESS '02: McMaster University Software Engineering Symposium*.
7.  **[Jump up^][Jump up 3]** pr1. ["Exploiting SPARC Buffer Overflow vulnerabilities"][Exploiting SPARC Buffer Overflow vulnerabilities].
8.  **[Jump up^][Jump up 4]** Curious (2005-01-08). ["Reverse engineering - PowerPC Cracking on Mac OS X with GDB"][Reverse engineering - PowerPC Cracking on Mac OS X with GDB]. *[Phrack][]*. **11** (63): 16.
9.  **[Jump up^][Jump up 5]** Sovarel, Ana Nora; Evans, David; Paul, Nathanael.["Where’s the FEEB? The Effectiveness of Instruction Set Randomization"][Where_s the FEEB_ The Effectiveness of Instruction Set Randomization].
10. **[Jump up^][Jump up 6]** Zhodiac (2001-12-28). ["HP-UX (PA-RISC 1.1) Overflows"][HP-UX _PA-RISC 1.1_ Overflows]. *[Phrack][]*. **11** (58): 11.
11. **[Jump up^][Jump up 7]** Foster, James C.; Osipov, Vitaly; Bhalla, Nish; Heinen, Niels (2005). [*Buffer Overflow Attacks: Detect, Exploit, Prevent*][Buffer Overflow Attacks_ Detect_ Exploit_ Prevent] (PDF). United States of America: Syngress Publishing, Inc. [ISBN][] [1-932266-67-4][].
12. **[Jump up^][Jump up 8]** Nergal (2001-12-28). ["The advanced return-into-lib(c) exploits: PaX case study"][The advanced return-into-lib_c_ exploits_ PaX case study]. *[Phrack][]*. **11** (58): 4.
13. **[Jump up^][Jump up 9]** Checkoway, S.; Davi, L.; Dmitrienko, A.; Sadeghi, A. R.; Shacham, H.; Winandy, M. (October 2010). "Return-Oriented Programming without Returns". *Proceedings of the 17th ACM conference on Computer and communications security - CCS '10*. pp. 559–572. [ISBN][] [978-1-4503-0245-6][].[doi][]:[10.1145/1866307.1866370][10.1145_1866307.1866370].

[https_en.wikipedia.org_wiki_Stack_buffer_overflow]: https://en.wikipedia.org/wiki/Stack_buffer_overflow
[Stack overflow _disambiguation]: https://en.wikipedia.org/wiki/Stack_overflow_%28disambiguation%29
[memory]: https://en.wikipedia.org/wiki/Computer_memory
[call stack]: https://en.wikipedia.org/wiki/Call_stack
[1]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-cert1-1
[2]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-dowd-2
[buffer overflow]: https://en.wikipedia.org/wiki/Buffer_overflow
[webserver]: https://en.wikipedia.org/wiki/Webserver
[attackers]: https://en.wikipedia.org/wiki/Hacker_%28computer_security%29
[3]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-aleph1-3
[4]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-microsoft1-4
[5]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-forest-5
[1Exploiting stack buffer overflows]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiting_stack_buffer_overflows
[2Platform related differences]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Platform_related_differences
[2.1Stacks that grow up]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stacks_that_grow_up
[3Protection schemes]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Protection_schemes
[3.1Stack canaries]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stack_canaries
[3.2Nonexecutable stack]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Nonexecutable_stack
[3.3Randomization]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Randomization
[4Notable examples]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Notable_examples
[5See also]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#See_also
[6References]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#References
[edit]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=1
[6]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-openbsd1-6
[figure B]: https://upload.wikimedia.org/wikipedia/commons/9/93/Stack_Overflow_3.png
[20170816112322927]: /images/20220610/5f57e06d8c0b43d99125d9cb989dfc87.png
[figure C]: https://upload.wikimedia.org/wikipedia/commons/c/c3/Stack_Overflow_4.png
[shellcode]: https://en.wikipedia.org/wiki/Shellcode
[SUID]: https://en.wikipedia.org/wiki/Setuid
[superuser]: https://en.wikipedia.org/wiki/Superuser
[edit 1]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=2
[RISC]: https://en.wikipedia.org/wiki/RISC
[7]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-prl-7
[8]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-curious1-8
[9]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-feeb-9
[edit 2]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=3
[10]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-zhodiac-10
[edit 3]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=4
[Buffer overflow protection]: https://en.wikipedia.org/wiki/Buffer_overflow_protection
[control-flow integrity]: https://en.wikipedia.org/wiki/Control-flow_integrity
[edit 4]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=5
[Canary value]: https://en.wikipedia.org/wiki/Canary_value
[canary in a coal mine]: https://en.wikipedia.org/wiki/Animal_sentinel#Historical_examples
[edit 5]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=6
[Data Execution Prevention]: https://en.wikipedia.org/wiki/Data_Execution_Prevention
[W_X]: https://en.wikipedia.org/wiki/W%5EX
[11]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-syngress1-11
[return to libc]: https://en.wikipedia.org/wiki/Return-to-libc_attack
[12]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-nergal-12
[return-oriented programming]: https://en.wikipedia.org/wiki/Return-oriented_programming
[13]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_note-13
[edit 6]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=7
[ASLR]: https://en.wikipedia.org/wiki/ASLR
[PIE]: https://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables
[edit 7]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=8
[Morris worm]: https://en.wikipedia.org/wiki/Morris_worm
[Unix]: https://en.wikipedia.org/wiki/Unix
[finger]: https://en.wikipedia.org/wiki/Finger_protocol
[1 1]: http://www.ee.ryerson.ca/~elf/hack/iworm.html
[Witty worm]: https://en.wikipedia.org/wiki/Witty_worm
[Internet Security Systems]: https://en.wikipedia.org/wiki/Internet_Security_Systems
[2 1]: http://www.icsi.berkeley.edu/~nweaver/login_witty.txt
[Slammer worm]: https://en.wikipedia.org/wiki/SQL_Slammer
[Microsoft]: https://en.wikipedia.org/wiki/Microsoft
[3 1]: https://www.wired.com/wired/archive/11.07/slammer.html
[Blaster worm]: https://en.wikipedia.org/wiki/Blaster_worm
[DCOM]: https://en.wikipedia.org/wiki/Distributed_Component_Object_Model
[Wii]: https://en.wikipedia.org/wiki/Wii
[The Legend of Zelda_ Twilight Princess]: https://en.wikipedia.org/wiki/The_Legend_of_Zelda:_Twilight_Princess
[Super Smash Bros. Brawl]: https://en.wikipedia.org/wiki/Super_Smash_Bros._Brawl
[modifications]: https://en.wikipedia.org/wiki/Mod_%28video_gaming%29
[edit 8]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=9
[icon]: https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Monitor_padlock.svg/31px-Monitor_padlock.svg.png
[icon 1]: https://en.wikipedia.org/wiki/File:Monitor_padlock.svg
[Computer security portal]: https://en.wikipedia.org/wiki/Portal:Computer_security
[Address space layout randomization]: https://en.wikipedia.org/wiki/Address_space_layout_randomization
[Computer security]: https://en.wikipedia.org/wiki/Computer_security
[ExecShield]: https://en.wikipedia.org/wiki/ExecShield
[Executable space protection]: https://en.wikipedia.org/wiki/Executable_space_protection
[Exploit _computer security]: https://en.wikipedia.org/wiki/Exploit_%28computer_security%29
[Format string attack]: https://en.wikipedia.org/wiki/Format_string_attack
[grsecurity]: https://en.wikipedia.org/wiki/Grsecurity
[Heap overflow]: https://en.wikipedia.org/wiki/Heap_overflow
[Integer overflow]: https://en.wikipedia.org/wiki/Integer_overflow
[NX bit]: https://en.wikipedia.org/wiki/NX_bit
[PaX]: https://en.wikipedia.org/wiki/PaX
[Security-Enhanced Linux]: https://en.wikipedia.org/wiki/Security-Enhanced_Linux
[Stack overflow]: https://en.wikipedia.org/wiki/Stack_overflow
[Storage violation]: https://en.wikipedia.org/wiki/Storage_violation
[Vulnerability _computing]: https://en.wikipedia.org/wiki/Vulnerability_%28computing%29
[edit 9]: https://en.wikipedia.org/w/index.php?title=Stack_buffer_overflow&action=edit&section=10
[Jump up to_a]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-cert1_1-0
[b]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-cert1_1-1
[VT-MB. Violation of Memory Bounds]: https://www.securecoding.cert.org/confluence/display/sci/VT-MB.+Violation+of+Memory+Bounds
[US CERT]: https://en.wikipedia.org/wiki/US_CERT
[Jump up to_a 1]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-dowd_2-0
[b 1]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-dowd_2-1
[c]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-dowd_2-2
[Addison Wesley]: https://en.wikipedia.org/wiki/Addison_Wesley
[ISBN]: https://en.wikipedia.org/wiki/International_Standard_Book_Number
[0-321-44442-6]: https://en.wikipedia.org/wiki/Special:BookSources/0-321-44442-6
[Jump up to_a 2]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-aleph1_3-0
[b 2]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-aleph1_3-1
[c 1]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-aleph1_3-2
[Levy_ Elias]: https://en.wikipedia.org/wiki/Elias_Levy
[Smashing The Stack for Fun and Profit]: http://www.phrack.org/issues/49/14.html#article
[Phrack]: https://en.wikipedia.org/wiki/Phrack
[Jump up]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-microsoft1_4-0
[Beyond Stack Smashing_ Recent Advances in Exploiting Buffer Overruns]: http://www.cs.berkeley.edu/~daw/teaching/cs261-f07/reading/beyondsmashing.pdf
[doi]: https://en.wikipedia.org/wiki/Digital_object_identifier
[10.1109_MSP.2004.36]: https://doi.org/10.1109%2FMSP.2004.36
[Jump up 1]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-forest_5-0
[Stack Overflows]: http://web.archive.org/web/20070928100343/http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf
[the original]: http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf
[Jump up 2]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-openbsd1_6-0
[OpenBSD_ Fix the Bugs_ Secure the System]: http://www.openbsd.org/slides/musess_2002/img16.htm
[Jump up 3]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-prl_7-0
[Exploiting SPARC Buffer Overflow vulnerabilities]: http://www.utdallas.edu/~edsha/UGsecurity/sparcoverflow.htm
[Jump up 4]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-curious1_8-0
[Reverse engineering - PowerPC Cracking on Mac OS X with GDB]: http://www.phrack.org/issues.html?issue=63&id=16#article
[Jump up 5]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-feeb_9-0
[Where_s the FEEB_ The Effectiveness of Instruction Set Randomization]: http://www.cs.virginia.edu/feeb/paper/
[Jump up 6]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-zhodiac_10-0
[HP-UX _PA-RISC 1.1_ Overflows]: http://www.phrack.org/issues.html?issue=58&id=11
[Jump up 7]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-syngress1_11-0
[Buffer Overflow Attacks_ Detect_ Exploit_ Prevent]: http://apossum.alfaspace.net/eng/Syngress.Buffer.Overflow.Attacks.Dec.2004.ISBN1932266674.pdf
[1-932266-67-4]: https://en.wikipedia.org/wiki/Special:BookSources/1-932266-67-4
[Jump up 8]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-nergal_12-0
[The advanced return-into-lib_c_ exploits_ PaX case study]: http://www.phrack.org/issues.html?issue=58&id=4#article
[Jump up 9]: https://en.wikipedia.org/wiki/Stack_buffer_overflow#cite_ref-13
[978-1-4503-0245-6]: https://en.wikipedia.org/wiki/Special:BookSources/978-1-4503-0245-6
[10.1145_1866307.1866370]: https://doi.org/10.1145%2F1866307.1866370