CWE-121: Stack-based Buffer Overflow

Description

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

Potential Impact

Availability

Modify Memory, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Integrity, Confidentiality, Availability, Access Control

Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism

Integrity, Confidentiality, Availability, Access Control, Other

Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Other

Demonstrative Examples

While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows:

Bad

#define BUFSIZE 256int 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.

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

Bad

void host_lookup(char *user_supplied_addr){
                        struct hostent *hp;in_addr_t *addr;char hostname[64];in_addr_t inet_addr(const char *cp);
                           
                           /*routine that ensures user_supplied_addr is in the right format for conversion */
                           
                           validate_addr_form(user_supplied_addr);addr = inet_addr(user_supplied_addr);hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);strcpy(hostname, hp->h_name);
                     }

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

Mitigations & Prevention

OperationBuild and Compilation Defense in Depth

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.

Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Implementation

Implement and perform bounds checking on input.

Implementation

Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.

OperationBuild and Compilation Defense in Depth

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 mo

Detection Methods

Fuzzing High — Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption,
Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea
Automated Dynamic Analysis Moderate — Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].

Real-World CVE Examples

CVE ID	Description
CVE-2021-35395	Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.

Taxonomy Mappings

CLASP: — Stack overflow
Software Fault Patterns: SFP8 — Faulty Buffer Access
CERT C Secure Coding: ARR38-C — Guarantee that library functions do not form invalid pointers
CERT C Secure Coding: STR31-C — Guarantee that storage for strings has sufficient space for character data and the null terminator

Frequently Asked Questions

What is CWE-121?

CWE-121 (Stack-based Buffer Overflow) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

How can CWE-121 be exploited?

Attackers can exploit CWE-121 (Stack-based Buffer Overflow) to modify memory, dos: crash, exit, or restart, dos: resource consumption (cpu), dos: resource consumption (memory). This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-121?

Key mitigations include: 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 G

What is the severity of CWE-121?

CWE-121 is classified as a Variant-level weakness (Low-Medium abstraction). It has been observed in 1 real-world CVEs.