CWE-122
Heap-based Buffer Overflow
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
Mitigation
Phases:
Description:
- Pre-design: Use a language or compiler that performs automatic bounds checking.
Mitigation
Phase: Architecture and Design
Description:
- Use an abstraction library to abstract away risky APIs. Not a complete solution.
Mitigation ID: MIT-10
Phases: Operation, Build and Compilation
Strategy: Environment Hardening
Description:
- 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.
Mitigation ID: MIT-11
Phases: Operation, Build and Compilation
Strategy: Environment Hardening
Description:
- 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].
Mitigation
Phase: Implementation
Description:
- Implement and perform bounds checking on input.
Mitigation
Phase: Implementation
Strategy: Libraries or Frameworks
Description:
- Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.
Mitigation
Phase: Operation
Description:
- Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.
CAPEC-92: Forced Integer Overflow
This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.