Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Opis

The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer.

Inne nazwy

Classic Buffer Overflow

This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.

Unbounded Transfer

Skutki

• Integrity, Confidentiality, Availability

  Modify Memory; Execute Unauthorized Code or Commands

  Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.

• Availability

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

  Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.

Zapobieganie

• Requirements · Language Selection

  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

  For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

  Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

• Architecture and Design · Libraries or Frameworks

  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

  Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

• 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

• Implementation

  Consider adhering to the following rules when allocating and managing an application's memory:

  - Double check that your buffer is as large as you specify.

  - When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

  - Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.

  - If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

• Implementation · Input Validation

  Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

  Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

• Architecture and Design

  For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

• 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

• Operation · Environment Hardening

  Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

  For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

  Skuteczność: Defense in Depth

• Build and Compilation, Operation

  Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.

• Implementation

  Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

  Skuteczność: Moderate

• Architecture and Design · Enforcement by Conversion

  When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

• Architecture and Design, Operation · Environment Hardening

  Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

• Architecture and Design, Operation · Sandbox or Jail

  Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

  Be careful to avoid CWE-243 and other weaknesses related to jails.

  Skuteczność: Limited

Przykłady podatności

• CVE-2000-1094 buffer overflow using command with long argument
• CVE-1999-0046 buffer overflow in local program using long environment variable
• CVE-2002-1337 buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
• CVE-2003-0595 By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
• CVE-2001-0191 By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.

Słabość nadrzędna

• CWE-787 Out-of-bounds Write
• CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
• CWE-20 Improper Input Validation

Może prowadzić do

• CWE-123 Write-what-where Condition

Słabości podrzędne

• CWE-785 Use of Path Manipulation Function without Maximum-sized Buffer

Kiedy powstaje

• Implementation

Dotyczy

Memory-Unsafe, C, C++, Assembly

Uwagi

A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much data is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.

At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.

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.

Źródła

1. Writing Secure Code — Michael Howard, David LeBlanc, Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127, Microsoft Press, 2002
2. 24 Deadly Sins of Software Security — Michael Howard, David LeBlanc, John Viega, "Sin 5: Buffer Overruns." Page 89, McGraw-Hill, 2010
3. Using the Strsafe.h Functions — Microsoft
4. Safe C String Library v1.0.3 — Matt Messier, John Viega
5. Address Space Layout Randomization in Windows Vista — Michael Howard
6. Limiting buffer overflows with ExecShield — Arjan van de Ven
7. PaX
8. Top 25 Series - Rank 3 - Classic Buffer Overflow — Jason Lam, SANS Software Security Institute, 2010
9. Understanding DEP as a mitigation technology part 1 — Microsoft
10. Least Privilege — Sean Barnum, Michael Gegick, 2005
11. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 3, "Nonexecutable Stack", Page 76, Addison Wesley, 2006
12. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 5, "Protection Mechanisms", Page 189, Addison Wesley, 2006
13. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 8, "C String Handling", Page 388, Addison Wesley, 2006
14. Position Independent Executables (PIE) — Grant Murphy, Red Hat, 2012
15. Automated Source Code Reliability Measure (ASCRM) — Object Management Group (OMG), ASCRM-CWE-120, 2016
16. Automated Source Code Security Measure (ASCSM) — Object Management Group (OMG), ASCSM-CWE-120, 2016
17. Prelink and address space randomization — John Richard Moser, 2006
18. Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR — Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh, 2016
19. Stack Frame Canary Validation (D3-SFCV) — D3FEND, 2023
20. Segment Address Offset Randomization (D3-SAOR) — D3FEND, 2023
21. Process Segment Execution Prevention (D3-PSEP) — D3FEND, 2023
22. Bypassing Browser Memory Protections: Setting back browser security by 10 years — Alexander Sotirov and Mark Dowd, Memory information leaks, 2008
23. State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation — Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, Rama S. Moorthy, 2014
24. AddressSanitizer