Stack-based Buffer Overflow

Opis

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).

Inne nazwy

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.

Stack Buffer Overflow

Skutki

• Availability

  Modify Memory; DoS: Crash, Exit, or Restart; DoS: 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.

• Integrity, Confidentiality, Availability, Access Control

  Modify Memory; Execute Unauthorized Code or Commands; Bypass 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.

• Integrity, Confidentiality, Availability, Access Control, Other

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

  When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

Zapobieganie

• Operation, Build and Compilation · 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.

  Skuteczność: Defense in Depth

• 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.

• Operation, Build and Compilation · 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].

  Skuteczność: Defense in Depth

Przykłady podatności

• 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.

Słabość nadrzędna

• CWE-788 Access of Memory Location After End of Buffer
• CWE-787 Out-of-bounds Write

Kiedy powstaje

• Implementation

Dotyczy

Memory-Unsafe, C, C++, Not Technology-Specific

Uwagi

There is significant inconsistency regarding the "buffer overflow" term, which can have multiple interpretations and uses. Many people mean "writing past the end of a buffer." Others mean "writing past the end of a buffer, or before the beginning of a buffer." Still others might include "read" in the term.

Stack-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 index overwrites or write-what-where condition, etc.

Źródła

1. Smashing The Stack For Fun And Profit — Aleph One, Phrack, 1996
2. Writing Secure Code — Michael Howard, David LeBlanc, Chapter 5, "Stack Overruns" Page 129, Microsoft Press, 2002
3. 24 Deadly Sins of Software Security — Michael Howard, David LeBlanc, John Viega, "Sin 5: Buffer Overruns." Page 89, McGraw-Hill, 2010
4. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 3, "Nonexecutable Stack", Page 76, Addison Wesley, 2006
5. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 5, "Protection Mechanisms", Page 189, Addison Wesley, 2006
6. The CLASP Application Security Process — Secure Software, Inc., 2005
7. Address Space Layout Randomization in Windows Vista — Michael Howard
8. PaX
9. Position Independent Executables (PIE) — Grant Murphy, Red Hat, 2012
10. Prelink and address space randomization — John Richard Moser, 2006
11. Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR — Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh, 2016
12. Stack Frame Canary Validation (D3-SFCV) — D3FEND, 2023
13. Segment Address Offset Randomization (D3-SAOR) — D3FEND, 2023
14. Bypassing Browser Memory Protections: Setting back browser security by 10 years — Alexander Sotirov and Mark Dowd, Memory information leaks, 2008
15. Secure by Design Alert: Eliminating Buffer Overflow Vulnerabilities — Cybersecurity and Infrastructure Security Agency, 2025
16. AddressSanitizer