How To Protect from Stack Overflows

There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which he places arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be used to then access arbitrary memory elsewhere in the system.

• Pre-design: Use a language or compiler that performs automatic bounds checking.
• Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.
• Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.
• Implementation: Check stack buffer boundaries before copy or concatenation.
• Operational: Use OS-level preventative functionality. Not a complete solution.