Editing Buffer overflow protection (section)

==Overview==
{{Main|Stack buffer overflow}}
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, which is usually a fixed-length buffer.  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).  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.<ref>{{cite web |last1=Fithen |first1=William L. |last2=Seacord |first2=Robert |publisher=[[US CERT]] |title=VT-MB. Violation of Memory Bounds |url=https://www.securecoding.cert.org/confluence/display/sci/VT-MB.+Violation+of+Memory+Bounds |date=2007-03-27 }}</ref>

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 if it accepts data from untrusted network hosts (for example, a public [[webserver]]), then the bug is a potential security vulnerability that allows an [[hacker (computer security)|attacker]] 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.<ref>{{cite journal |last=Levy |first=Elias |author-link=Elias Levy |title=Smashing The Stack for Fun and Profit |journal=[[Phrack]] |volume=7 |issue=49 |page=14 |date=1996-11-08 |url=http://www.phrack.org/issues/49/14.html#article }}</ref>

Typically, buffer overflow protection modifies the organization of data in the [[stack frame]] of a [[function call]] to include a "canary" value that, when destroyed, shows that a buffer preceding it in memory has been overflowed.  This provides the benefit of preventing an entire class of attacks. According to some researchers,<ref>{{cite web|url=https://www.cpe.ku.ac.th/~mcs/courses/2005_02/214573/papers/buffer_overflows.pdf |title=Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade* |url-status=dead |archive-url=https://web.archive.org/web/20130309083252/http://tmp-www.cpe.ku.ac.th/~mcs/courses/2005_02/214573/papers/buffer_overflows.pdf |archive-date=2013-03-09 }}</ref> the performance impact of these techniques is negligible.

Stack-smashing protection is unable to protect against certain forms of attack. For example, it cannot protect against buffer overflows in the heap.  There is no sane way to alter the layout of data within a [[Data structure|structure]]; structures are expected to be the same between modules, especially with shared libraries. Any data in a structure after a buffer is impossible to protect with canaries; thus, programmers must be very careful about how they organize their variables and use their structures.