Stack buffer overflow

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.

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.

[3][4][5] 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).

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.

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.

However, 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.

[11] 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 memcpy.

[citation needed] Over the years, a number of control-flow integrity schemes have been developed to inhibit malicious stack buffer overflow exploitation.

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.

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.

These so-called gadgets each accomplish some simple register manipulation or similar execution before returning, and stringing them together achieves the attacker's ends.

[14] Instead of separating the code from the data, another mitigation technique is to introduce randomization to the memory space of the executing program.

[18] A limitation of ASLR realization on 64-bit systems is that it is vulnerable to memory disclosure and information leakage attacks.