Stack-based Buffer Overflow
Draft Variant
Structure: Simple
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).
Common Consequences 3
Scope: Availability
Impact: Modify MemoryDoS: Crash, Exit, or RestartDoS: Resource Consumption (CPU)DoS: Resource Consumption (Memory)
Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Scope: IntegrityConfidentialityAvailabilityAccess Control
Impact: Modify MemoryExecute Unauthorized Code or CommandsBypass Protection Mechanism
Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.
Scope: IntegrityConfidentialityAvailabilityAccess ControlOther
Impact: Modify MemoryExecute Unauthorized Code or CommandsBypass Protection MechanismOther
When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
Detection Methods 2
FuzzingHigh
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, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.Automated Static AnalysisHigh
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 searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)Potential Mitigations 5
Phase: OperationBuild and Compilation
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
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: OperationBuild 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
Demonstrative Examples 2
While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows:
Code Example:
Bad
C
cThe buffer size is fixed, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.
ID : DX-1
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.Code Example:
Bad
C
c/*routine that ensures user_supplied_addr is in the right format for conversion /
cThis 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 (Unchecked Return Value) that can lead to a NULL pointer dereference (NULL Pointer Dereference).
Observed Examples 1
CVE-2021-35395Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.
References 15
Smashing The Stack For Fun And Profit
Aleph One
Phrack
08-11-1996
ID: REF-1029
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
ID: REF-7
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
Address Space Layout Randomization in Windows Vista
Michael Howard
ID: REF-58
Position Independent Executables (PIE)
Grant Murphy
Red Hat
28-11-2012
ID: REF-64
Prelink and address space randomization
John Richard Moser
05-07-2006
https://lwn.net/Articles/190139/(2023-04-26)
ID: REF-1332
Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR
Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh
2016
http://www.cs.ucr.edu/~nael/pubs/micro16.pdf(2023-04-26)
ID: REF-1333
Stack Frame Canary Validation (D3-SFCV)
D3FEND
2023
ID: REF-1334
Segment Address Offset Randomization (D3-SAOR)
D3FEND
2023
ID: REF-1335
Bypassing Browser Memory Protections: Setting back browser security by 10 years
Alexander Sotirov and Mark Dowd
2008
ID: REF-1337
Secure by Design Alert: Eliminating Buffer Overflow Vulnerabilities
Cybersecurity and Infrastructure Security Agency
12-02-2025
ID: REF-1477
Likelihood of Exploit
High
Applicable Platforms
Languages:
C : OftenC++ : Often
Modes of Introduction
Implementation
Alternate Terms
Stack Overflow
"Stack Overflow" is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged.Functional Areas
- Memory Management
Affected Resources
- Memory
Related Weaknesses
Taxonomy Mapping
- CLASP
- Software Fault Patterns
- CERT C Secure Coding
- CERT C Secure Coding
Notes
OtherStack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc.