Improper Restriction of Operations within the Bounds of a Memory BufferID: 119 | Date: (C)2012-05-14 (M)2022-10-10 | Type: weakness | Status: USABLE | Abstraction Type: Class |
Description The software performs operations on a memory buffer, but it can
read from or write to a memory location that is outside of the intended boundary
of the buffer. Extended DescriptionCertain languages allow direct addressing of memory locations and do not
automatically ensure that these locations are valid for the memory buffer
that is being referenced. This can cause read or write operations to be
performed on memory locations that may be associated with other variables,
data structures, or internal program data.As a result, an attacker may be able to execute arbitrary code, alter the
intended control flow, read sensitive information, or cause the system to
crash. Likelihood of Exploit: High Applicable PlatformsLanguage: OftenLanguage: CLanguage: OftenLanguage: C++Language: AssemblyLanguage Class: Languages without memory management support Time Of Introduction - Architecture and Design
- Implementation
- Operation
Related Attack Patterns Common Consequences Scope | Technical Impact | Notes |
---|
IntegrityConfidentialityAvailability | Execute unauthorized code or
commandsModify memory | If the memory accessible by the attacker can be effectively
controlled, it may be possible to execute arbitrary code, as with a
standard buffer overflow.If the attacker can overwrite a pointer's worth of memory (usually 32
or 64 bits), he can redirect a function pointer to his own malicious
code. Even when the attacker can only modify a single byte arbitrary
code execution can be possible. Sometimes this is because the same
problem can be exploited repeatedly to the same effect. Other times it
is because the attacker can overwrite security-critical
application-specific data -- such as a flag indicating whether the user
is an administrator. | AvailabilityConfidentiality | Read memoryDoS: crash / exit /
restartDoS: resource consumption
(CPU)DoS: resource consumption
(memory) | Out of bounds memory access will very likely result in the corruption
of relevant memory, and perhaps instructions, possibly leading to a
crash. Other attacks leading to lack of availability are possible,
including putting the program into an infinite loop. | Confidentiality | Read memory | In the case of an out-of-bounds read, the attacker may have access to
sensitive information. If the sensitive information contains system
details, such as the current buffers position in memory, this knowledge
can be used to craft further attacks, possibly with more severe
consequences. |
Detection Methods Name | Description | Effectiveness | Notes |
---|
Automated Static Analysis | This weakness can often be detected using automated static analysis
tools. Many modern tools use data flow analysis or constraint-based
techniques to minimize the number of false positives.Automated static analysis generally does not account for environmental
considerations when reporting out-of-bounds memory operations. This can
make it difficult for users to determine which warnings should be
investigated first. For example, an analysis tool might report buffer
overflows that originate from command line arguments in a program that
is not expected to run with setuid or other special privileges. | High | | Automated Dynamic Analysis | This weakness can be detected using dynamic tools and techniques that
interact with the software using large test suites with many diverse
inputs, such as fuzz testing (fuzzing), robustness testing, and fault
injection. The software's operation may slow down, but it should not
become unstable, crash, or generate incorrect results. | | |
Potential Mitigations Phase | Strategy | Description | Effectiveness | Notes |
---|
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 [R.119.3], and the Strsafe.h library from Microsoft [R.119.2].
These libraries provide safer versions of overflow-prone string-handling
functions. | | This is not a complete solution, since many buffer overflows are not
related to strings. | Build and Compilation | Compilation or Build Hardening | Run or compile the software using features or extensions that
automatically provide a protection mechanism that mitigates or
eliminates buffer overflows.For example, certain compilers and extensions provide automatic buffer
overflow detection mechanisms that are built into the compiled code.
Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat
FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice. | Defense in Depth | This is not necessarily a complete solution, since these mechanisms
can only detect certain types of overflows. In addition, an attack could
still cause a denial of service, since the typical response is to exit
the application. | Implementation | | Consider adhering to the following rules when allocating and managing
an application's memory: | | | Operation | Environment Hardening | Use a feature like Address Space Layout Randomization (ASLR) [R.119.4]
[R.119.6]. | Defense in Depth | This is not a complete solution. However, it forces the attacker to
guess an unknown value that changes every program execution. In
addition, an attack could still cause a denial of service, since the
typical response is to exit the application. | Operation | Environment Hardening | Use a CPU and operating system that offers Data Execution Protection
(NX) or its equivalent [R.119.6] [R.119.7]. | Defense in Depth | This is not a complete solution, since buffer overflows could be used
to overwrite nearby variables to modify the software's state in
dangerous ways. In addition, it cannot be used in cases in which
self-modifying code is required. Finally, an attack could still cause a
denial of service, since the typical response is to exit the
application. | Implementation | | Replace unbounded copy functions with analogous functions that support
length arguments, such as strcpy with strncpy. Create these if they are
not available. | Moderate | This approach is still susceptible to calculation errors, including
issues such as off-by-one errors (CWE-193) and incorrectly calculating
buffer lengths (CWE-131). |
Relationships Related CWE | Type | View | Chain |
---|
CWE-119 ChildOf CWE-890 | Category | CWE-888 | |
Demonstrative Examples (Details) - In the following code, the method retrieves a value from an array at
a specific array index location that is given as an input parameter to the
method (Demonstrative Example Id DX-100)
- The following example asks a user for an offset into an array to
select an item. (Demonstrative Example Id DX-90)
- This example applies an encoding procedure to an input string and
stores it into a buffer. (Demonstrative Example Id DX-19)
- 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. (Demonstrative Example Id DX-1)
Observed Examples - CVE-2009-2550 : Classic stack-based buffer overflow in media player using a long entry in a playlist
- CVE-2009-2403 : Heap-based buffer overflow in media player using a long entry in a playlist
- CVE-2009-0689 : large precision value in a format string triggers overflow
- CVE-2009-0690 : negative offset value leads to out-of-bounds read
- CVE-2009-1532 : malformed inputs cause accesses of uninitialized or previously-deleted objects, leading to memory corruption
- CVE-2009-1528 : chain: lack of synchronization leads to memory corruption
- CVE-2009-0558 : attacker-controlled array index leads to code execution
- CVE-2009-0269 : chain: -1 value from a function call was intended to indicate an error, but is used as an array index instead.
- CVE-2009-0566 : chain: incorrect calculations lead to incorrect pointer dereference and memory corruption
- CVE-2009-1350 : product accepts crafted messages that lead to a dereference of an arbitrary pointer
- CVE-2009-0191 : chain: malformed input causes dereference of uninitialized memory
- CVE-2008-4113 : OS kernel trusts userland-supplied length value, allowing reading of sensitive information
For more examples, refer to CVE relations in the bottom box. White Box Definitions None Black Box Definitions None Taxynomy Mappings Taxynomy | Id | Name | Fit |
---|
OWASP Top Ten 2004 | A5 | Buffer Overflows | Exact | CERT C Secure Coding | ARR00-C | Understand how arrays work | | CERT C Secure Coding | ARR33-C | Guarantee that copies are made into storage of sufficient
size | | CERT C Secure Coding | ARR34-C | Ensure that array types in expressions are
compatible | | CERT C Secure Coding | ARR35-C | Do not allow loops to iterate beyond the end of an
array | | CERT C Secure Coding | ENV01-C | Do not make assumptions about the size of an environment
variable | | CERT C Secure Coding | FIO37-C | Do not assume character data has been read | | CERT C Secure Coding | MEM09-C | Do not assume memory allocation routines initialize
memory | | CERT C Secure Coding | STR31-C | Guarantee that storage for strings has sufficient space for
character data and the null terminator | | CERT C Secure Coding | STR32-C | Null-terminate byte strings as required | | CERT C Secure Coding | STR33-C | Size wide character strings correctly | | WASC | 7 | Buffer Overflow | | CERT C++ Secure Coding | ARR00-CPP | Understand when to prefer vectors over
arrays | | CERT C++ Secure Coding | ARR30-CPP | Guarantee that array and vector indices are within the valid
range | | CERT C++ Secure Coding | ARR33-CPP | Guarantee that copies are made into storage of sufficient
size | | CERT C++ Secure Coding | ARR35-CPP | Do not allow loops to iterate beyond the end of an array or
container | | CERT C++ Secure Coding | STR31-CPP | Guarantee that storage for character arrays has sufficient
space for character data and the null terminator | | CERT C++ Secure Coding | STR32-CPP | Null-terminate character arrays as required | | CERT C++ Secure Coding | MEM09-CPP | Do not assume memory allocation routines initialize
memory | | CERT C++ Secure Coding | FIO37-CPP | Do not assume character data has been read | | CERT C++ Secure Coding | ENV01-CPP | Do not make assumptions about the size of an environment
variable | |
References: - M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127;
Chapter 14, "Prevent I18N Buffer Overruns" Page 441'. Published on 2002.
- Microsoft .Using the Strsafe.h Functions.
- Matt Messier John Viega .Safe C String Library v1.0.3.
- Michael Howard .Address Space Layout Randomization in Windows
Vista.
- Arjan van de Ven .Limiting buffer overflows with ExecShield.
- .PaX.
- Microsoft .Understanding DEP as a mitigation technology part
1.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 5, "Memory Corruption", Page 167.'. Published on 2006.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 5, "Protection Mechanisms", Page
189.'. Published on 2006.
|