316
Strategy = Environment Hardening
Use automatic buffer overflow detection mechanisms that are offered by certain compilers or
compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat
FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms
including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary
Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
Effectiveness = Defense in Depth
This is not necessarily a complete solution, since these mechanisms only detect certain types of
overflows. In addition, the result is still a denial of service, since the typical response is to exit the
application.
Phase: Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Phase: Implementation
Implement and perform bounds checking on input.
Phase: Implementation
Do not use dangerous functions such as gets. Use safer, equivalent functions which check for
boundary errors.
Phase: Operation
Phase: Build and Compilation
Strategy = Environment Hardening
Run or compile the software using features or extensions that randomly arrange the positions
of a program's executable and libraries in memory. Because this makes the addresses
unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples
include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-
Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their
default memory addresses conflict with other modules, in a process known as "rebasing" (for
Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR
for libraries cannot be used in conjunction with prelink since it would require relocating the
libraries at run-time, defeating the whole purpose of prelinking. For more information on these
techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Effectiveness = Defense in Depth
These techniques do not provide a complete solution. For instance, exploits frequently use a bug
that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It
has also been shown that a side-channel attack can bypass ASLR [REF-1333]
Demonstrative Examples
Example 1:
While buffer overflow examples can be rather complex, it is possible to have very simple, yet still
exploitable, stack-based buffer overflows:
Example Language: C (Bad)
#define BUFSIZE 256
int main(int argc, char **argv) {
char buf[BUFSIZE];
strcpy(buf, argv[1]);
}
The buffer size is fixed, but there is no guarantee the string in argv[1] will not exceed this size and
cause an overflow.
CWE Version 4.14
CWE-121: Stack-based Buffer Overflow
CWE-121: Stack-based Buffer Overflow