| Home > CWE List > VIEW SLICE: CWE-1154: Weaknesses Addressed by the SEI CERT C Coding Standard (4.20) |
|
CWE VIEW: Weaknesses Addressed by the SEI CERT C Coding Standard
CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the online wiki that reflects that current rules and recommendations of the SEI CERT C Coding Standard.
The following graph shows the tree-like relationships between
weaknesses that exist at different levels of abstraction. At the highest level, categories
and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are
special CWE entries used to group weaknesses that share a common characteristic. Pillars are
weaknesses that are described in the most abstract fashion. Below these top-level entries
are weaknesses are varying levels of abstraction. Classes are still very abstract, typically
independent of any specific language or technology. Base level weaknesses are used to
present a more specific type of weakness. A variant is a weakness that is described at a
very low level of detail, typically limited to a specific language or technology. A chain is
a set of weaknesses that must be reachable consecutively in order to produce an exploitable
vulnerability. While a composite is a set of weaknesses that must all be present
simultaneously in order to produce an exploitable vulnerability.
Show Details:
1154 - Weaknesses Addressed by the SEI CERT C Coding Standard
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1155
(SEI CERT C Coding Standard - Guidelines 01. Preprocessor (PRE))
Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1156
(SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL))
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1156
(SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) >
562
(Return of Stack Variable Address)
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP))
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
908
(Use of Uninitialized Resource)
The product uses or accesses a resource that has not been initialized.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
476
(NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL.
NPD
null deref
NPE
nil pointer dereference
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
690
(Unchecked Return Value to NULL Pointer Dereference)
The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
628
(Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
685
(Function Call With Incorrect Number of Arguments)
The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
686
(Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
843
(Access of Resource Using Incompatible Type ('Type Confusion'))
The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.
Object Type Confusion
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
481
(Assigning instead of Comparing)
The code uses an operator for assignment when the intention was to perform a comparison.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT))
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
190
(Integer Overflow or Wraparound)
The product performs a calculation that can
produce an integer overflow or wraparound when the logic
assumes that the resulting value will always be larger than
the original value. This occurs when an integer value is
incremented to a value that is too large to store in the
associated representation. When this occurs, the value may
become a very small or negative number.
Overflow
Wraparound
wrap, wrap-around, wrap around
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
131
(Incorrect Calculation of Buffer Size)
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
191
(Integer Underflow (Wrap or Wraparound))
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.
Integer underflow
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
680
(Integer Overflow to Buffer Overflow)
The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
192
(Integer Coercion Error)
Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
197
(Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
681
(Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
194
(Unexpected Sign Extension)
The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
195
(Signed to Unsigned Conversion Error)
The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
369
(Divide By Zero)
The product divides a value by zero.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
682
(Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
587
(Assignment of a Fixed Address to a Pointer)
The product sets a pointer to a specific address other than NULL or 0.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP))
Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
682
(Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
681
(Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
197
(Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR))
Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
129
(Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
out-of-bounds array index
index-out-of-range
array index underflow
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
786
(Access of Memory Location Before Start of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
123
(Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
469
(Use of Pointer Subtraction to Determine Size)
The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
121
(Stack-based Buffer Overflow)
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).
Stack Overflow
Stack Buffer Overflow
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
805
(Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
468
(Incorrect Pointer Scaling)
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR))
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
120
(Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
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.
Classic Buffer Overflow
Unbounded Transfer
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
121
(Stack-based Buffer Overflow)
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).
Stack Overflow
Stack Buffer Overflow
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
122
(Heap-based Buffer Overflow)
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
Heap Overflow
Heap Buffer Overflow
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
123
(Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
170
(Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM))
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
416
(Use After Free)
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Dangling pointer
UAF
Use-After-Free
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
672
(Operation on a Resource after Expiration or Release)
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
666
(Operation on Resource in Wrong Phase of Lifetime)
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
415
(Double Free)
The product calls free() twice on the same memory address.
Double-free
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
401
(Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Memory Leak
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
459
(Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used.
Insufficient Cleanup
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
771
(Missing Reference to Active Allocated Resource)
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
772
(Missing Release of Resource after Effective Lifetime)
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
590
(Free of Memory not on the Heap)
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
131
(Incorrect Calculation of Buffer Size)
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
680
(Integer Overflow to Buffer Overflow)
The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
467
(Use of sizeof() on a Pointer Type)
The code calls sizeof() on a pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
789
(Memory Allocation with Excessive Size Value)
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
Stack Exhaustion
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
190
(Integer Overflow or Wraparound)
The product performs a calculation that can
produce an integer overflow or wraparound when the logic
assumes that the resulting value will always be larger than
the original value. This occurs when an integer value is
incremented to a value that is too large to store in the
associated representation. When this occurs, the value may
become a very small or negative number.
Overflow
Wraparound
wrap, wrap-around, wrap around
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO))
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
134
(Use of Externally-Controlled Format String)
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
20
(Improper Input Validation)
The product receives input or data, but it does
not validate or incorrectly validates that the input has the
properties that are required to process the data safely and
correctly.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
67
(Improper Handling of Windows Device Names)
The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
197
(Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
241
(Improper Handling of Unexpected Data Type)
The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
664
(Improper Control of a Resource Through its Lifetime)
The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
459
(Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used.
Insufficient Cleanup
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
772
(Missing Release of Resource after Effective Lifetime)
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
773
(Missing Reference to Active File Descriptor or Handle)
The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
775
(Missing Release of File Descriptor or Handle after Effective Lifetime)
The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
771
(Missing Reference to Active Allocated Resource)
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
910
(Use of Expired File Descriptor)
The product uses or accesses a file descriptor after it has been closed.
Stale file descriptor
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
666
(Operation on Resource in Wrong Phase of Lifetime)
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
672
(Operation on a Resource after Expiration or Release)
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
686
(Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
685
(Function Call With Incorrect Number of Arguments)
The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV))
Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
705
(Incorrect Control Flow Scoping)
The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
78
(Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
Shell injection
Shell metacharacters
OS Command Injection
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
88
(Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1166
(SEI CERT C Coding Standard - Guidelines 11. Signals (SIG))
Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1166
(SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)) >
479
(Signal Handler Use of a Non-reentrant Function)
The product defines a signal handler that calls a non-reentrant function.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1166
(SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)) >
662
(Improper Synchronization)
The product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR))
Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
456
(Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
252
(Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
253
(Incorrect Check of Function Return Value)
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1168
(SEI CERT C Coding Standard - Guidelines 13. Application Programming Interfaces (API))
Weaknesses in this category are related to the rules and recommendations in the Application Programming Interfaces (API) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON))
Weaknesses in this category are related to the rules and recommendations in the Concurrency (CON) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
667
(Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
366
(Race Condition within a Thread)
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
377
(Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC))
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
338
(Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
331
(Insufficient Entropy)
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS))
Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
170
(Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
242
(Use of Inherently Dangerous Function)
The product calls a function that can never be guaranteed to work safely.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
363
(Race Condition Enabling Link Following)
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
696
(Incorrect Behavior Order)
The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways that may produce resultant weaknesses.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
273
(Improper Check for Dropped Privileges)
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
667
(Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
252
(Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
253
(Incorrect Check of Function Return Value)
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1172
(SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN))
Weaknesses in this category are related to the rules and recommendations in the Microsoft Windows (WIN) section of the SEI CERT C Coding Standard.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1172
(SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN)) >
762
(Mismatched Memory Management Routines)
The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1172
(SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN)) >
590
(Free of Memory not on the Heap)
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
Relationship
The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-786: Access of Memory Location Before Start of Buffer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 In the following C/C++ example, a utility function is used to trim trailing whitespace from a character string. The function copies the input string to a local character string and uses a while statement to remove the trailing whitespace by moving backward through the string and overwriting whitespace with a NUL character. (bad code)
Example Language: C
char* trimTrailingWhitespace(char *strMessage, int length) {
char *retMessage;
char *message = malloc(sizeof(char)*(length+1)); // copy input string to a temporary string char message[length+1]; int index; for (index = 0; index < length; index++) { message[index] = strMessage[index]; }message[index] = '\0'; // trim trailing whitespace int len = index-1; while (isspace(message[len])) { message[len] = '\0'; }len--; // return string without trailing whitespace retMessage = message; return retMessage; However, this function can cause a buffer underwrite if the input character string contains all whitespace. On some systems the while statement will move backwards past the beginning of a character string and will call the isspace() function on an address outside of the bounds of the local buffer. Example 2 The following example asks a user for an offset into an array to select an item. (bad code)
Example Language: C
int main (int argc, char **argv) { char *items[] = {"boat", "car", "truck", "train"}; }int index = GetUntrustedOffset(); printf("You selected %s\n", items[index-1]); The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126). Example 3 The following is an example of code that may result in a buffer underwrite. This code is attempting to replace the substring "Replace Me" in destBuf with the string stored in srcBuf. It does so by using the function strstr(), which returns a pointer to the found substring in destBuf. Using pointer arithmetic, the starting index of the substring is found. (bad code)
Example Language: C
int main() {
... }
char *result = strstr(destBuf, "Replace Me"); int idx = result - destBuf; strcpy(&destBuf[idx], srcBuf); ... In the case where the substring is not found in destBuf, strstr() will return NULL, causing the pointer arithmetic to be undefined, potentially setting the value of idx to a negative number. If idx is negative, this will result in a buffer underwrite of destBuf. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.
When the product accesses the resource using an incompatible type, this could trigger logical errors because the resource does not have expected properties. In languages without memory safety, such as C and C++, type confusion can lead to out-of-bounds memory access. While this weakness is frequently associated with unions when parsing data with many different embedded object types in C, it can be present in any application that can interpret the same variable or memory location in multiple ways. This weakness is not unique to C and C++. For example, errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type. (bad code)
Example Language: C
#define NAME_TYPE 1
#define ID_TYPE 2 struct MessageBuffer { int msgType; };union { char *name; };int nameID; int main (int argc, char **argv) { struct MessageBuffer buf;
char *defaultMessage = "Hello World"; buf.msgType = NAME_TYPE; buf.name = defaultMessage; printf("Pointer of buf.name is %p\n", buf.name); /* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */ buf.nameID = (int)(defaultMessage + 1); printf("Pointer of buf.name is now %p\n", buf.name); if (buf.msgType == NAME_TYPE) { printf("Message: %s\n", buf.name); }else { printf("Message: Use ID %d\n", buf.nameID); }The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation. As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string. Execution of the program might generate output such as:
Pointer of name is 10830
Pointer of name is now 10831
Message: ello World
Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified. In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes. Example 2 The following PHP code accepts a value, adds 5, and prints the sum. (bad code)
Example Language: PHP
$value = $_GET['value'];
$sum = $value + 5; echo "value parameter is '$value'<p>"; echo "SUM is $sum"; When called with the following query string:
value=123
the program calculates the sum and prints out:
SUM is 128
However, the attacker could supply a query string such as:
value[]=123
The "[]" array syntax causes $value to be treated as an array type, which then generates a fatal error when calculating $sum:
Fatal error: Unsupported operand types in program.php on line 2
Example 3 The following Perl code is intended to look up the privileges for user ID's between 0 and 3, by performing an access of the $UserPrivilegeArray reference. It is expected that only userID 3 is an admin (since this is listed in the third element of the array). (bad code)
Example Language: Perl
my $UserPrivilegeArray = ["user", "user", "admin", "user"];
my $userID = get_current_user_ID(); if ($UserPrivilegeArray eq "user") { print "Regular user!\n"; }else { print "Admin!\n"; }print "\$UserPrivilegeArray = $UserPrivilegeArray\n"; In this case, the programmer intended to use "$UserPrivilegeArray->{$userID}" to access the proper position in the array. But because the subscript was omitted, the "user" string was compared to the scalar representation of the $UserPrivilegeArray reference, which might be of the form "ARRAY(0x229e8)" or similar. Since the logic also "fails open" (CWE-636), the result of this bug is that all users are assigned administrator privileges. While this is a forced example, it demonstrates how type confusion can have security consequences, even in memory-safe languages. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Applicable Platform This weakness is possible in any type-unsafe programming language. Research Gap Type confusion weaknesses have received some attention by applied researchers and major software vendors for C and C++ code. Some publicly-reported vulnerabilities probably have type confusion as a root-cause weakness, but these may be described as "memory corruption" instead. For other languages, there are very few public reports of type confusion weaknesses. These are probably under-studied. Since many programs rely directly or indirectly on loose typing, a potential "type confusion" behavior might be intentional, possibly requiring more manual analysis.
CWE-481: Assigning instead of Comparing
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code uses an operator for assignment when the intention was to perform a comparison.
In many languages the compare statement is very close in appearance to the assignment statement and are often confused. This bug is generally the result of a typo and usually causes obvious problems with program execution. If the comparison is in an if statement, the if statement will usually evaluate the value of the right-hand side of the predicate.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100. (bad code)
Example Language: C
int isValid(int value) {
if (value=100) { }printf("Value is valid\n"); }return(1); printf("Value is not valid\n"); return(0); (bad code)
Example Language: C#
bool isValid(int value) {
if (value=100) { }Console.WriteLine("Value is valid."); }return true; Console.WriteLine("Value is not valid."); return false; However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results. Example 2 In this example, we show how assigning instead of comparing can impact code when values are being passed by reference instead of by value. Consider a scenario in which a string is being processed from user input. Assume the string has already been formatted such that different user inputs are concatenated with the colon character. When the processString function is called, the test for the colon character will result in an insertion of the colon character instead, adding new input separators. Since the string was passed by reference, the data sentinels will be inserted in the original string (CWE-464), and further processing of the inputs will be altered, possibly malformed. (bad code)
Example Language: C
void processString (char *str) {
int i;
for(i=0; i<strlen(str); i++) { if (isalnum(str[i])){ }processChar(str[i]); }else if (str[i] = ':') { movingToNewInput();} }Example 3 The following Java example attempts to perform some processing based on the boolean value of the input parameter. However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". As with the previous examples, the variable will be reassigned locally and the expression in the if statement will evaluate to true and unintended processing may occur. (bad code)
Example Language: Java
public void checkValid(boolean isValid) {
if (isValid = true) { }System.out.println("Performing processing"); }doSomethingImportant(); else { System.out.println("Not Valid, do not perform processing"); }return; While most Java compilers will catch the use of an assignment operator when a comparison operator is required, for boolean variables in Java the use of the assignment operator within an expression is allowed. If possible, try to avoid using comparison operators on boolean variables in java. Instead, let the values of the variables stand for themselves, as in the following code. (good code)
Example Language: Java
public void checkValid(boolean isValid) {
if (isValid) { }System.out.println("Performing processing"); }doSomethingImportant(); else { System.out.println("Not Valid, do not perform processing"); }return; Alternatively, to test for false, just use the boolean NOT operator. (good code)
Example Language: Java
public void checkValid(boolean isValid) {
if (!isValid) { }System.out.println("Not Valid, do not perform processing"); }return; System.out.println("Performing processing"); doSomethingImportant(); Example 4 The following example demonstrates the weakness. (bad code)
Example Language: C
void called(int foo){
if (foo=1) printf("foo\n"); }int main() { called(2); return 0;
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-587: Assignment of a Fixed Address to a Pointer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function. (bad code)
Example Language: C
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b'); // Here we can inject code to execute. The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-805: Buffer Access with Incorrect Length Value
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
When the length value exceeds the size of the destination, a buffer overflow could occur.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 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. (bad code)
Example Language: C
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 under the assumption that the maximum length value of hostname is 64 bytes, 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). Example 2 In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: (bad code)
Example Language: C
int returnChunkSize(void *) {
/* if chunk info is valid, return the size of usable memory, * else, return -1 to indicate an error */ ... int main() { ... }memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1)); ... If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788). Example 3 In the following example, the source character string is copied to the dest character string using the method strncpy. (bad code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(source)-1); ... However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below. (good code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(dest)-1); ... Example 4 In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file. (bad code)
Example Language: C
#define LOG_INPUT_SIZE 40
// saves the file name to a log file int outputFilenameToLog(char *filename, int length) { int success;
// buffer with size set to maximum size for input to log file char buf[LOG_INPUT_SIZE]; // copy filename to buffer strncpy(buf, filename, length); // save to log file success = saveToLogFile(buf); return success; However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below. (good code)
Example Language: C
...
// copy filename to buffer strncpy(buf, filename, sizeof(buf)-1); ... Example 5 Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units, (one in bytes, the other in characters) making their use prone to error. In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow. The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string. (bad code)
Example Language: C
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1]; }MultiByteToWideChar(CP_ACP, 0, username, -1, unicodeUser, sizeof(unicodeUser)); NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info); This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated. If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array. (bad code)
Example Language: C
char last_name[20];
printf ("Enter your last name: "); scanf ("%s", last_name); The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. Example 2 The following code attempts to create a local copy of a buffer to perform some manipulations to the data. (bad code)
Example Language: C
void manipulate_string(char * string){
char buf[24]; }strcpy(buf, string); ... However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter. Example 3 The code below calls the gets() function to read in data from the command line. (bad code)
Example Language: C
char buf[24]; }printf("Please enter your name and press <Enter>\n"); gets(buf); ... However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition. Example 4 In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file. (bad code)
Example Language: C
...
struct hostent *clienthp;
char hostname[MAX_LEN]; // create server socket, bind to server address and listen on socket ... // accept client connections and process requests int count = 0; for (count = 0; count < MAX_CONNECTIONS; count++) { int clientlen = sizeof(struct sockaddr_in); int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen); if (clientsocket >= 0) { clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name); logOutput("Accepted client connection from host ", hostname); // process client request ... close(clientsocket); close(serversocket); ... However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship
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.
Terminology
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.
Other
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.
CWE-369: Divide By Zero
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur. (bad code)
Example Language: Java
public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests; }By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception. (good code)
Example Language: Java
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) { }System.out.println("Division by zero attempted!"); }throw ArithmeticException; return totalTime / numRequests; Example 2 The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur. (bad code)
Example Language: C
double divide(double x, double y){
return x/y; }By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error. (good code)
Example Language: C
const int DivideByZero = 10;
double divide(double x, double y){ if ( 0 == y ){ }throw DivideByZero; }return x/y; ... try{ divide(10, 0); }catch( int i ){ if(i==DivideByZero) { }cerr<<"Divide by zero error"; }
Example 3 The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur. (bad code)
Example Language: C#
int Division(int x, int y){
return (x / y); }The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero. (good code)
Example Language: C#
int SafeDivision(int x, int y){
try{ }return (x / y); }catch (System.DivideByZeroException dbz){ System.Console.WriteLine("Division by zero attempted!"); }return 0;
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-415: Double Free
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code shows a simple example of a double free vulnerability. (bad code)
Example Language: C
char* ptr = (char*)malloc (SIZE);
... if (abrt) {
free(ptr);
}... free(ptr); Double free vulnerabilities have two common (and sometimes overlapping) causes:
Although some double free vulnerabilities are not much more complicated than this example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once. Example 2 While contrived, this code should be exploitable on Linux distributions that do not ship with heap-chunk check summing turned on. (bad code)
Example Language: C
#include <stdio.h>
#include <unistd.h> #define BUFSIZE1 512 #define BUFSIZE2 ((BUFSIZE1/2) - 8) int main(int argc, char **argv) { char *buf1R1; }char *buf2R1; char *buf1R2; buf1R1 = (char *) malloc(BUFSIZE2); buf2R1 = (char *) malloc(BUFSIZE2); free(buf1R1); free(buf2R1); buf1R2 = (char *) malloc(BUFSIZE1); strncpy(buf1R2, argv[1], BUFSIZE1-1); free(buf2R1); free(buf1R2); Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship
This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.
Theoretical
It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.
CWE-590: Free of Memory not on the Heap
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
When free() is called on an invalid pointer, the program's memory management data structures may become corrupted. This corruption can cause the program to crash or, in some circumstances, an attacker may be able to cause free() to operate on controllable memory locations to modify critical program variables or execute code.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 In this example, an array of record_t structs, bar, is allocated automatically on the stack as a local variable and the programmer attempts to call free() on the array. The consequences will vary based on the implementation of free(), but it will not succeed in deallocating the memory. (bad code)
Example Language: C
void foo(){
record_t bar[MAX_SIZE];
/* do something interesting with bar */ ... free(bar); This example shows the array allocated globally, as part of the data segment of memory and the programmer attempts to call free() on the array. (bad code)
Example Language: C
record_t bar[MAX_SIZE]; //Global var
void foo(){ /* do something interesting with bar */ ... free(bar); Instead, if the programmer wanted to dynamically manage the memory, malloc() or calloc() should have been used. (good code)
Example Language: C
void foo(){
record_t *bar = (record_t*)malloc(MAX_SIZE*sizeof(record_t));
/* do something interesting with bar */ ... free(bar); Additionally, global variables could be passed to free() when they are pointers to dynamically allocated memory. (good code)
Example Language: C
record_t *bar; //Global var
void foo(){ bar = (record_t*)malloc(MAX_SIZE*sizeof(record_t));
/* do something interesting with bar */ ... free(bar); Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Other
CWE-686: Function Call With Incorrect Argument Type
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
This weakness is most likely to occur in loosely typed languages, or in strongly typed languages in which the types of variable arguments cannot be enforced at compilation time, or where there is implicit casting.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-685: Function Call With Incorrect Number of Arguments
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-628: Function Call with Incorrectly Specified Arguments
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
There are multiple ways in which this weakness can be introduced, including:
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order. (bad code)
Example Language: PHP
function authenticate($username, $password) {
// authenticate user ... authenticate($_POST['password'], $_POST['username']); Example 2 This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit. (bad code)
Example Language: Perl
sub ReportAuth {
my ($username, $result, $fatal) = @_; }PrintLog("auth: username=%s, result=%d", $username, $result); if (($result ne "success") && $fatal) { die "Failed!\n"; }sub PrivilegedFunc { my $result = CheckAuth($username); }ReportAuth($username, $result, 0); DoReallyImportantStuff(); Example 3 In the following Java snippet, the accessGranted() method is accidentally called with the static ADMIN_ROLES array rather than the user roles. (bad code)
Example Language: Java
private static final String[] ADMIN_ROLES = ...;
public boolean void accessGranted(String resource, String user) { String[] userRoles = getUserRoles(user); }return accessGranted(resource, ADMIN_ROLES); private boolean void accessGranted(String resource, String[] userRoles) { // grant or deny access based on user roles ... Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-122: Heap-based Buffer Overflow
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, heap-based buffer overflows: (bad code)
Example Language: C
#define BUFSIZE 256
int main(int argc, char **argv) { char *buf; }buf = (char *)malloc(sizeof(char)*BUFSIZE); strcpy(buf, argv[1]); The buffer is allocated heap memory with a fixed size, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow. Example 2 This example applies an encoding procedure to an input string and stores it into a buffer. (bad code)
Example Language: C
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE); if ( MAX_SIZE <= strlen(user_supplied_string) ){ die("user string too long, die evil hacker!"); }dst_index = 0; for ( i = 0; i < strlen(user_supplied_string); i++ ){ if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&'; }dst_buf[dst_index++] = 'a'; dst_buf[dst_index++] = 'm'; dst_buf[dst_index++] = 'p'; dst_buf[dst_index++] = ';'; else if ('<' == user_supplied_string[i] ){ /* encode to < */ else dst_buf[dst_index++] = user_supplied_string[i]; return dst_buf; The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Terminology
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.
CWE-273: Improper Check for Dropped Privileges
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
If the drop fails, the product will continue to run with the raised privileges, which might provide additional access to unprivileged users.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 This code attempts to take on the privileges of a user before creating a file, thus avoiding performing the action with unnecessarily high privileges: (bad code)
Example Language: C++
bool DoSecureStuff(HANDLE hPipe) {
bool fDataWritten = false; }ImpersonateNamedPipeClient(hPipe); HANDLE hFile = CreateFile(...); /../ RevertToSelf() /../ The call to ImpersonateNamedPipeClient may fail, but the return value is not checked. If the call fails, the code may execute with higher privileges than intended. In this case, an attacker could exploit this behavior to write a file to a location that the attacker does not have access to. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-664: Improper Control of a Resource Through its Lifetime
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
Resources often have explicit instructions on how to be created, used and destroyed. When code does not follow these instructions, it can lead to unexpected behaviors and potentially exploitable states. Even without explicit instructions, various principles are expected to be adhered to, such as "Do not use an object until after its creation is complete," or "do not use an object after it has been slated for destruction." This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 This code allocates a socket and forks each time it receives a new connection. (bad code)
Example Language: C
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) { newsock=accept(sock, ...); }printf("A connection has been accepted\n"); pid = fork(); The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Maintenance
More work is needed on this entry and its children. There are perspective/layering issues; for example, one breakdown is based on lifecycle phase (CWE-404, CWE-665), while other children are independent of lifecycle, such as CWE-400. Others do not specify as many bases or variants, such as CWE-704, which primarily covers numbers at this stage.
CWE-241: Improper Handling of Unexpected Data Type
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-67: Improper Handling of Windows Device Names
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
Not properly handling virtual filenames (e.g. AUX, CON, PRN, COM1, LPT1) can result in different types of vulnerabilities. In some cases an attacker can request a device via injection of a virtual filename in a URL, which may cause an error that leads to a denial of service or an error page that reveals sensitive information. A product that allows device names to bypass filtering runs the risk of an attacker injecting malicious code in a file with the name of a device.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-20: Improper Input Validation
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterInput validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. Input can consist of:
Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data. Many properties of raw data or metadata may need to be validated upon entry into the code, such as:
Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated. (bad code)
Example Language: Java
...
public static final double price = 20.00; int quantity = currentUser.getAttribute("quantity"); double total = price * quantity; chargeUser(total); ... The user has no control over the price variable, however the code does not prevent a negative value from being specified for quantity. If an attacker were to provide a negative value, then the user would have their account credited instead of debited. Example 2 This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares. (bad code)
Example Language: C
...
#define MAX_DIM 100 ... /* board dimensions */ int m,n, error; board_square_t *board; printf("Please specify the board height: \n"); error = scanf("%d", &m); if ( EOF == error ){ die("No integer passed: Die evil hacker!\n"); }printf("Please specify the board width: \n"); error = scanf("%d", &n); if ( EOF == error ){ die("No integer passed: Die evil hacker!\n"); }if ( m > MAX_DIM || n > MAX_DIM ) { die("Value too large: Die evil hacker!\n"); }board = (board_square_t*) malloc( m * n * sizeof(board_square_t)); ... While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program. Example 3 The following example shows a PHP application in which the programmer attempts to display a user's birthday and homepage. (bad code)
Example Language: PHP
$birthday = $_GET['birthday'];
$homepage = $_GET['homepage']; echo "Birthday: $birthday<br>Homepage: <a href=$homepage>click here</a>" The programmer intended for $birthday to be in a date format and $homepage to be a valid URL. However, since the values are derived from an HTTP request, if an attacker can trick a victim into clicking a crafted URL with <script> tags providing the values for birthday and / or homepage, then the script will run on the client's browser when the web server echoes the content. Notice that even if the programmer were to defend the $birthday variable by restricting input to integers and dashes, it would still be possible for an attacker to provide a string of the form: (attack code)
2009-01-09--
If this data were used in a SQL statement, it would treat the remainder of the statement as a comment. The comment could disable other security-related logic in the statement. In this case, encoding combined with input validation would be a more useful protection mechanism. Furthermore, an XSS (CWE-79) attack or SQL injection (CWE-89) are just a few of the potential consequences when input validation is not used. Depending on the context of the code, CRLF Injection (CWE-93), Argument Injection (CWE-88), or Command Injection (CWE-77) may also be possible. Example 4 The following example takes a user-supplied value to allocate an array of objects and then operates on the array. (bad code)
Example Language: Java
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){ }die("Negative value supplied for list size, die evil hacker!"); }Widget[] list = new Widget [ untrustedListSize ]; list[0] = new Widget(); This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown. Example 5 This Android application has registered to handle a URL when sent an intent: (bad code)
Example Language: Java
... IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL"); MyReceiver receiver = new MyReceiver(); registerReceiver(receiver, filter); ... public class UrlHandlerReceiver extends BroadcastReceiver { @Override
public void onReceive(Context context, Intent intent) { if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length(); ... } The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks. Multiple techniques exist to transform potentially dangerous input into something safe, which is different than "validation," which is a technique to check if an input is already safe. CWE users need to be cautious during root cause analysis to ensure that an issue is truly an input-validation problem. Terminology The "input validation" term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships. Some people use "input validation" as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, i.e., attempting to remove dangerous inputs (related to CWE-790); encoding/escaping, i.e., attempting to ensure that the input is not misinterpreted when it is included in output to another component (related to CWE-116); or canonicalization, which often indirectly removes otherwise-dangerous inputs. Others use the term in a narrower context to simply mean "checking if an input conforms to expectations without changing it." CWE uses this narrow interpretation. Note that "input validation" has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation. Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred. Developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person's last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded. Maintenance
As of 2020, this entry is used more often than preferred, and it is a source of frequent confusion. It is being actively modified for CWE 4.1 and subsequent versions.
Maintenance Maintenance
Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.
CWE-667: Improper Locking
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 In the following Java snippet, methods are defined to get and set a long field in an instance of a class that is shared across multiple threads. Because operations on double and long are nonatomic in Java, concurrent access may cause unexpected behavior. Thus, all operations on long and double fields should be synchronized. (bad code)
Example Language: Java
private long someLongValue;
public long getLongValue() { return someLongValue; }public void setLongValue(long l) { someLongValue = l; }Example 2 This code tries to obtain a lock for a file, then writes to it. (bad code)
Example Language: PHP
function writeToLog($message){
$logfile = fopen("logFile.log", "a"); }//attempt to get logfile lock if (flock($logfile, LOCK_EX)) { fwrite($logfile,$message); }// unlock logfile flock($logfile, LOCK_UN); else { print "Could not obtain lock on logFile.log, message not recorded\n"; }fclose($logFile); PHP by default will wait indefinitely until a file lock is released. If an attacker is able to obtain the file lock, this code will pause execution, possibly leading to denial of service for other users. Note that in this case, if an attacker can perform an flock() on the file, they may already have privileges to destroy the log file. However, this still impacts the execution of other programs that depend on flock(). Example 3 The following function attempts to acquire a lock in order to perform operations on a shared resource. (bad code)
Example Language: C
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */ pthread_mutex_unlock(mutex); However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior. In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels. (good code)
Example Language: C
int f(pthread_mutex_t *mutex) {
int result;
result = pthread_mutex_lock(mutex); if (0 != result) return result;
/* access shared resource */ return pthread_mutex_unlock(mutex); Example 4 It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization... (bad code)
Example Language: Java
if (helper == null) {
synchronized (this) {
if (helper == null) { }helper = new Helper(); }return helper; The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called. Suppose that helper is not initialized. Then, thread A sees that helper==null and enters the synchronized block and begins to execute: (bad code)
Example Language: Java
helper = new Helper();
If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Maintenance
Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.
CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string.
When creating commands using interpolation into a string, developers may assume that only the arguments/options that they specify will be processed. This assumption may be even stronger when the programmer has encoded the command in a way that prevents separate commands from being provided maliciously, e.g. in the case of shell metacharacters. When constructing the command, the developer may use whitespace or other delimiters that are required to separate arguments when the command. However, if an attacker can provide an untrusted input that contains argument-separating delimiters, then the resulting command will have more arguments than intended by the developer. The attacker may then be able to change the behavior of the command. Depending on the functionality supported by the extraneous arguments, this may have security-relevant consequences. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 Consider the following program. It intends to perform an "ls -l" on an input filename. The validate_name() subroutine performs validation on the input to make sure that only alphanumeric and "-" characters are allowed, which avoids path traversal (CWE-22) and OS command injection (CWE-78) weaknesses. Only filenames like "abc" or "d-e-f" are intended to be allowed. (bad code)
Example Language: Perl
my $arg = GetArgument("filename");
do_listing($arg); sub do_listing {
my($fname) = @_;
}
if (! validate_name($fname)) {
print "Error: name is not well-formed!\n";
}return; # build command my $cmd = "/bin/ls -l $fname"; system($cmd); sub validate_name {
my($name) = @_;
}
if ($name =~ /^[\w\-]+$/) {
return(1);
}else {
return(0);
}However, validate_name() allows filenames that begin with a "-". An adversary could supply a filename like "-aR", producing the "ls -l -aR" command (CWE-88), thereby getting a full recursive listing of the entire directory and all of its sub-directories. There are a couple possible mitigations for this weakness. One would be to refactor the code to avoid using system() altogether, instead relying on internal functions. Another option could be to add a "--" argument to the ls command, such as "ls -l --", so that any remaining arguments are treated as filenames, causing any leading "-" to be treated as part of a filename instead of another option. Another fix might be to change the regular expression used in validate_name to force the first character of the filename to be a letter or number, such as: (good code)
Example Language: Perl
if ($name =~ /^\w[\w\-]+$/) ...
Example 2 CVE-2016-10033 / [REF-1249] provides a useful real-world example of this weakness within PHPMailer. The program calls PHP's mail() function to compose and send mail. The fifth argument to mail() is a set of parameters. The program intends to provide a "-fSENDER" parameter, where SENDER is expected to be a well-formed email address. The program has already validated the e-mail address before invoking mail(), but there is a lot of flexibility in what constitutes a well-formed email address, including whitespace. With some additional allowed characters to perform some escaping, the adversary can specify an additional "-o" argument (listing an output file) and a "-X" argument (giving a program to execute). Additional details for this kind of exploit are in [REF-1250]. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship
At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags.
CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications. Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have. The problem is exacerbated if the compromised process does not follow the principle of least privilege, because the attacker-controlled commands may run with special system privileges that increases the amount of damage. There are at least two subtypes of OS command injection:
From a weakness standpoint, these variants represent distinct programmer errors. In the first variant, the programmer clearly intends that input from untrusted parties will be part of the arguments in the command to be executed. In the second variant, the programmer does not intend for the command to be accessible to any untrusted party, but the programmer probably has not accounted for alternate ways in which malicious attackers can provide input. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 This example code intends to take the name of a user and list the contents of that user's home directory. It is subject to the first variant of OS command injection. (bad code)
Example Language: PHP
$userName = $_POST["user"];
$command = 'ls -l /home/' . $userName; system($command); The $userName variable is not checked for malicious input. An attacker could set the $userName variable to an arbitrary OS command such as: (attack code)
;rm -rf /
Which would result in $command being: (result)
ls -l /home/;rm -rf /
Since the semi-colon is a command separator in Unix, the OS would first execute the ls command, then the rm command, deleting the entire file system. Also note that this example code is vulnerable to Path Traversal (CWE-22) and Untrusted Search Path (CWE-426) attacks. Example 2 The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system. (bad code)
Example Language: C
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat "; }strcat(cmd, argv[1]); system(cmd); Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition. Note that if argv[1] is a very long argument, then this issue might also be subject to a buffer overflow (CWE-120). Example 3 This example is a web application that intends to perform a DNS lookup of a user-supplied domain name. It is subject to the first variant of OS command injection. (bad code)
Example Language: Perl
use CGI qw(:standard);
$name = param('name'); $nslookup = "/path/to/nslookup"; print header; if (open($fh, "$nslookup $name|")) { while (<$fh>) { }print escapeHTML($_); }print "<br>\n"; close($fh); Suppose an attacker provides a domain name like this: (attack code)
cwe.mitre.org%20%3B%20/bin/ls%20-l
The "%3B" sequence decodes to the ";" character, and the %20 decodes to a space. The open() statement would then process a string like this: (result)
/path/to/nslookup cwe.mitre.org ; /bin/ls -l
As a result, the attacker executes the "/bin/ls -l" command and gets a list of all the files in the program's working directory. The input could be replaced with much more dangerous commands, such as installing a malicious program on the server. Example 4 The example below reads the name of a shell script to execute from the system properties. It is subject to the second variant of OS command injection. (bad code)
Example Language: Java
String script = System.getProperty("SCRIPTNAME");
if (script != null) System.exec(script);
If an attacker has control over this property, then they could modify the property to point to a dangerous program. Example 5 In the example below, a method is used to transform geographic coordinates from latitude and longitude format to UTM format. The method gets the input coordinates from a user through a HTTP request and executes a program local to the application server that performs the transformation. The method passes the latitude and longitude coordinates as a command-line option to the external program and will perform some processing to retrieve the results of the transformation and return the resulting UTM coordinates. (bad code)
Example Language: Java
public String coordinateTransformLatLonToUTM(String coordinates)
{ String utmCoords = null;
try { String latlonCoords = coordinates;
Runtime rt = Runtime.getRuntime(); Process exec = rt.exec("cmd.exe /C latlon2utm.exe -" + latlonCoords); // process results of coordinate transform // ... catch(Exception e) {...} return utmCoords; However, the method does not verify that the contents of the coordinates input parameter includes only correctly-formatted latitude and longitude coordinates. If the input coordinates were not validated prior to the call to this method, a malicious user could execute another program local to the application server by appending '&' followed by the command for another program to the end of the coordinate string. The '&' instructs the Windows operating system to execute another program. Example 6 The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user. (bad code)
Example Language: Java
...
String btype = request.getParameter("backuptype"); String cmd = new String("cmd.exe /K \" c:\\util\\rmanDB.bat "
+btype+ "&&c:\\utl\\cleanup.bat\"") System.Runtime.getRuntime().exec(cmd); ... The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well. Example 7 The following code is a wrapper around the UNIX command cat which prints the contents of a file to standard out. It is also injectable: (bad code)
Example Language: C
#include <stdio.h>
#include <unistd.h> int main(int argc, char **argv) { char cat[] = "cat "; char *command; size_t commandLength; commandLength = strlen(cat) + strlen(argv[1]) + 1; command = (char *) malloc(commandLength); strncpy(command, cat, commandLength); strncat(command, argv[1], (commandLength - strlen(cat)) ); system(command); return (0); Used normally, the output is simply the contents of the file requested, such as Story.txt: (informative)
./catWrapper Story.txt
(result)
When last we left our heroes...
However, if the provided argument includes a semicolon and another command, such as: (attack code)
Story.txt; ls
Then the "ls" command is executed by catWrapper with no complaint: (result)
./catWrapper Story.txt; ls
Two commands would then be executed: catWrapper, then ls. The result might look like: (result)
When last we left our heroes...
Story.txt SensitiveFile.txt PrivateData.db a.out* If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege. Example 8 This example takes user input, passes it through an encoding scheme, then lists the contents of the user's home directory based on the user name. (bad code)
Example Language: Perl
sub GetUntrustedInput {
return($ARGV[0]); }sub encode { my($str) = @_; }$str =~ s/\&/\&/gs; $str =~ s/\"/\"/gs; $str =~ s/\'/\'/gs; $str =~ s/\</\</gs; $str =~ s/\>/\>/gs; return($str); sub doit { my $uname = encode(GetUntrustedInput("username")); }print "<b>Welcome, $uname!</b><p>\n"; system("cd /home/$uname; /bin/ls -l"); The programmer attempts to encode dangerous characters, however the denylist for encoding is incomplete (CWE-184) and an attacker can still pass a semicolon, resulting in a chain with OS command injection (CWE-78). Additionally, the encoding routine is used inappropriately with command execution. An attacker doesn't even need to insert their own semicolon. The attacker can instead leverage the encoding routine to provide the semicolon to separate the commands. If an attacker supplies a string of the form: (attack code)
' pwd
then the program will encode the apostrophe and insert the semicolon, which functions as a command separator when passed to the system function. This allows the attacker to complete the command injection. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Terminology
The "OS command injection" phrase carries different meanings to different people. For some people, it only refers to cases in which the attacker injects command separators into arguments for an application-controlled program that is being invoked. For some people, it refers to any type of attack that can allow the attacker to execute OS commands of their own choosing. This usage could include untrusted search path weaknesses (CWE-426) that cause the application to find and execute an attacker-controlled program. Further complicating the issue is the case when argument injection (CWE-88) allows alternate command-line switches or options to be inserted into the command line, such as an "-exec" switch whose purpose may be to execute the subsequent argument as a command (this -exec switch exists in the UNIX "find" command, for example). In this latter case, however, CWE-88 could be regarded as the primary weakness in a chain with CWE-78.
Research Gap
More investigation is needed into the distinction between the OS command injection variants, including the role with argument injection (CWE-88). Equivalent distinctions may exist in other injection-related problems such as SQL injection.
CWE-170: Improper Null Termination
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
Null termination errors frequently occur in two different ways. An off-by-one error could cause a null to be written out of bounds, leading to an overflow. Or, a program could use a strncpy() function call incorrectly, which prevents a null terminator from being added at all. Other scenarios are possible.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a NULL terminator. (bad code)
Example Language: C
#define MAXLEN 1024
... char *pathbuf[MAXLEN]; ... read(cfgfile,inputbuf,MAXLEN); //does not null terminate strcpy(pathbuf,inputbuf); //requires null terminated input ... The code above will behave correctly if the data read from cfgfile is null terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected NULL character, the call to strcpy() will continue copying from memory until it encounters an arbitrary NULL character. This will likely overflow the destination buffer and, if the attacker can control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack. Example 2 In the following code, readlink() expands the name of a symbolic link stored in pathname and puts the absolute path into buf. The length of the resulting value is then calculated using strlen(). (bad code)
Example Language: C
char buf[MAXPATH];
... readlink(pathname, buf, MAXPATH); int length = strlen(buf); ... The code above will not always behave correctly as readlink() does not append a NULL byte to buf. Readlink() will stop copying characters once the maximum size of buf has been reached to avoid overflowing the buffer, this will leave the value buf not NULL terminated. In this situation, strlen() will continue traversing memory until it encounters an arbitrary NULL character further on down the stack, resulting in a length value that is much larger than the size of string. Readlink() does return the number of bytes copied, but when this return value is the same as stated buf size (in this case MAXPATH), it is impossible to know whether the pathname is precisely that many bytes long, or whether readlink() has truncated the name to avoid overrunning the buffer. In testing, vulnerabilities like this one might not be caught because the unused contents of buf and the memory immediately following it may be NULL, thereby causing strlen() to appear as if it is behaving correctly. Example 3 While the following example is not exploitable, it provides a good example of how nulls can be omitted or misplaced, even when "safe" functions are used: (bad code)
Example Language: C
#include <stdio.h>
#include <string.h> int main() { char longString[] = "String signifying nothing"; char shortString[16]; strncpy(shortString, longString, 16); printf("The last character in shortString is: %c (%1$x)\n", shortString[15]); return (0); The above code gives the following output: "The last character in shortString is: n (6e)". So, the shortString array does not end in a NULL character, even though the "safe" string function strncpy() was used. The reason is that strncpy() does not impliciitly add a NULL character at the end of the string when the source is equal in length or longer than the provided size. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship
Factors: this is usually resultant from other weaknesses such as off-by-one errors, but it can be primary to boundary condition violations such as buffer overflows. In buffer overflows, it can act as an expander for assumed-immutable data.
Relationship
Overlaps missing input terminator.
Applicable Platform Conceptually, this does not just apply to the C language; any language or representation that involves a terminator could have this type of problem. Maintenance
As currently described, this entry is more like a category than a weakness.
CWE-404: Improper Resource Shutdown or Release
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not release or incorrectly releases a resource before it is made available for re-use.
When a resource is created or allocated, the developer is responsible for properly releasing the resource as well as accounting for all potential paths of expiration or invalidation, such as a set period of time or revocation.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called. (bad code)
Example Language: Java
private void processFile(string fName)
{ BufferReader fil = new BufferReader(new FileReader(fName)); }String line; while ((line = fil.ReadLine()) != null) { processLine(line); }The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure. (good code)
Example Language: Java
private void processFile(string fName)
{ BufferReader fil = new BufferReader(new FileReader(fName)); }String line; while ((line = fil.ReadLine()) != null) { processLine(line); }fil.Close(); Example 2 This code attempts to open a connection to a database and catches any exceptions that may occur. (bad code)
Example Language: Java
try {
Connection con = DriverManager.getConnection(some_connection_string); }catch ( Exception e ) { log( e ); }If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application. Example 3 Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries. (bad code)
Example Language: C#
...
SqlConnection conn = new SqlConnection(connString); SqlCommand cmd = new SqlCommand(queryString); cmd.Connection = conn; conn.Open(); SqlDataReader rdr = cmd.ExecuteReader(); HarvestResults(rdr); conn.Connection.Close(); ... Example 4 The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles. (bad code)
Example Language: C
int decodeFile(char* fName) {
char buf[BUF_SZ];
FILE* f = fopen(fName, "r"); if (!f) { printf("cannot open %s\n", fName); }return DECODE_FAIL; else { while (fgets(buf, BUF_SZ, f)) {
if (!checkChecksum(buf)) { }return DECODE_FAIL; }else { decodeBlock(buf); }fclose(f); return DECODE_SUCCESS; Example 5 In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource. (bad code)
Example Language: C++
class A {
void foo(); };void A::foo(){ int *ptr; }ptr = (int*)malloc(sizeof(int)); delete ptr; Example 6 In this example, the program calls the delete[] function on non-heap memory. (bad code)
Example Language: C++
class A{
void foo(bool); };void A::foo(bool heap) { int localArray[2] = { }11,22 };int *p = localArray; if (heap){ p = new int[2]; }delete[] p; Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 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. (bad code)
Example Language: C
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). Example 2 This example applies an encoding procedure to an input string and stores it into a buffer. (bad code)
Example Language: C
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE); if ( MAX_SIZE <= strlen(user_supplied_string) ){ die("user string too long, die evil hacker!"); }dst_index = 0; for ( i = 0; i < strlen(user_supplied_string); i++ ){ if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&'; }dst_buf[dst_index++] = 'a'; dst_buf[dst_index++] = 'm'; dst_buf[dst_index++] = 'p'; dst_buf[dst_index++] = ';'; else if ('<' == user_supplied_string[i] ){
/* encode to < */
}else dst_buf[dst_index++] = user_supplied_string[i]; return dst_buf; The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands. Example 3 The following example asks a user for an offset into an array to select an item. (bad code)
Example Language: C
int main (int argc, char **argv) { char *items[] = {"boat", "car", "truck", "train"}; }int index = GetUntrustedOffset(); printf("You selected %s\n", items[index-1]); The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126). Example 4 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 (bad code)
Example Language: C
int getValueFromArray(int *array, int len, int index) {
int value; // check that the array index is less than the maximum // length of the array if (index < len) {
// get the value at the specified index of the array
value = array[index]; // if array index is invalid then output error message // and return value indicating error else { printf("Value is: %d\n", array[index]); }value = -1; return value; However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer (CWE-127) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below. (good code)
Example Language: C
... // check that the array index is within the correct // range of values for the array if (index >= 0 && index < len) { ... Example 5 Windows provides the _mbs family of functions to perform various operations on multibyte strings. When these functions are passed a malformed multibyte string, such as a string containing a valid leading byte followed by a single null byte, they can read or write past the end of the string buffer causing a buffer overflow. The following functions all pose a risk of buffer overflow: _mbsinc _mbsdec _mbsncat _mbsncpy _mbsnextc _mbsnset _mbsrev _mbsset _mbsstr _mbstok _mbccpy _mbslen Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Applicable Platform It is possible in any programming languages without memory management support to attempt an operation outside of the bounds of a memory buffer, but the consequences will vary widely depending on the language, platform, and chip architecture.
CWE-662: Improper Synchronization
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
Synchronization refers to a variety of behaviors and mechanisms that allow two or more independently-operating processes or threads to ensure that they operate on shared resources in predictable ways that do not interfere with each other. Some shared resource operations cannot be executed atomically; that is, multiple steps must be guaranteed to execute sequentially, without any interference by other processes. Synchronization mechanisms vary widely, but they may include locking, mutexes, and semaphores. When a multi-step operation on a shared resource cannot be guaranteed to execute independent of interference, then the resulting behavior can be unpredictable. Improper synchronization could lead to data or memory corruption, denial of service, etc. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following function attempts to acquire a lock in order to perform operations on a shared resource. (bad code)
Example Language: C
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */ pthread_mutex_unlock(mutex); However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior. In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels. (good code)
Example Language: C
int f(pthread_mutex_t *mutex) {
int result;
result = pthread_mutex_lock(mutex); if (0 != result) return result;
/* access shared resource */ return pthread_mutex_unlock(mutex); Example 2 The following code intends to fork a process, then have both the parent and child processes print a single line. (bad code)
Example Language: C
static void print (char * string) {
char * word;
int counter; for (word = string; counter = *word++; ) { putc(counter, stdout);
fflush(stdout); /* Make timing window a little larger... */ sleep(1); int main(void) { pid_t pid;
pid = fork(); if (pid == -1) { exit(-2); }else if (pid == 0) { print("child\n"); }else { print("PARENT\n"); }exit(0); One might expect the code to print out something like:
PARENT
child
However, because the parent and child are executing concurrently, and stdout is flushed each time a character is printed, the output might be mixed together, such as:
PcAhRiElNdT
[blank line]
[blank line]
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Research Gap
Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.
CWE-129: Improper Validation of Array Index
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 In the code snippet below, an untrusted integer value is used to reference an object in an array. (bad code)
Example Language: Java
public String getValue(int index) {
return array[index]; }If index is outside of the range of the array, this may result in an ArrayIndexOutOfBounds Exception being raised. Example 2 The following example takes a user-supplied value to allocate an array of objects and then operates on the array. (bad code)
Example Language: Java
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){ }die("Negative value supplied for list size, die evil hacker!"); }Widget[] list = new Widget [ untrustedListSize ]; list[0] = new Widget(); This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown. Example 3 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 (bad code)
Example Language: C
int getValueFromArray(int *array, int len, int index) {
int value; // check that the array index is less than the maximum // length of the array if (index < len) {
// get the value at the specified index of the array
value = array[index]; // if array index is invalid then output error message // and return value indicating error else { printf("Value is: %d\n", array[index]); }value = -1; return value; However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer (CWE-127) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below. (good code)
Example Language: C
... // check that the array index is within the correct // range of values for the array if (index >= 0 && index < len) { ... Example 4 The following example retrieves the sizes of messages for a pop3 mail server. The message sizes are retrieved from a socket that returns in a buffer the message number and the message size, the message number (num) and size (size) are extracted from the buffer and the message size is placed into an array using the message number for the array index. (bad code)
Example Language: C
/* capture the sizes of all messages */ int getsizes(int sock, int count, int *sizes) { ...
char buf[BUFFER_SIZE]; int ok; int num, size; // read values from socket and added to sizes array while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0) {
// continue read from socket until buf only contains '.'
if (DOTLINE(buf)) break;
else if (sscanf(buf, "%d %d", &num, &size) == 2)sizes[num - 1] = size;
...
In this example the message number retrieved from the buffer could be a value that is outside the allowable range of indices for the array and could possibly be a negative number. Without proper validation of the value to be used for the array index an array overflow could occur and could potentially lead to unauthorized access to memory addresses and system crashes. The value of the array index should be validated to ensure that it is within the allowable range of indices for the array as in the following code. (good code)
Example Language: C
/* capture the sizes of all messages */ int getsizes(int sock, int count, int *sizes) { ...
char buf[BUFFER_SIZE]; int ok; int num, size; // read values from socket and added to sizes array while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0) { // continue read from socket until buf only contains '.' if (DOTLINE(buf)) break;
else if (sscanf(buf, "%d %d", &num, &size) == 2) { if (num > 0 && num <= (unsigned)count)
sizes[num - 1] = size;
else /* warn about possible attempt to induce buffer overflow */ report(stderr, "Warning: ignoring bogus data for message sizes returned by server.\n"); ...
Example 5 In the following example the method displayProductSummary is called from a Web service servlet to retrieve product summary information for display to the user. The servlet obtains the integer value of the product number from the user and passes it to the displayProductSummary method. The displayProductSummary method passes the integer value of the product number to the getProductSummary method which obtains the product summary from the array object containing the project summaries using the integer value of the product number as the array index. (bad code)
Example Language: Java
// Method called from servlet to obtain product information public String displayProductSummary(int index) { String productSummary = new String("");
try { String productSummary = getProductSummary(index);
} catch (Exception ex) {...} return productSummary; public String getProductSummary(int index) { return products[index]; }In this example the integer value used as the array index that is provided by the user may be outside the allowable range of indices for the array which may provide unexpected results or cause the application to fail. The integer value used for the array index should be validated to ensure that it is within the allowable range of indices for the array as in the following code. (good code)
Example Language: Java
// Method called from servlet to obtain product information public String displayProductSummary(int index) { String productSummary = new String("");
try { String productSummary = getProductSummary(index);
} catch (Exception ex) {...} return productSummary; public String getProductSummary(int index) { String productSummary = "";
if ((index >= 0) && (index < MAX_PRODUCTS)) { productSummary = products[index]; }else { System.err.println("index is out of bounds"); }throw new IndexOutOfBoundsException(); return productSummary; An alternative in Java would be to use one of the collection objects such as ArrayList that will automatically generate an exception if an attempt is made to access an array index that is out of bounds. (good code)
Example Language: Java
ArrayList productArray = new ArrayList(MAX_PRODUCTS);
... try { productSummary = (String) productArray.get(index); } catch (IndexOutOfBoundsException ex) {...}Example 6 The following example asks a user for an offset into an array to select an item. (bad code)
Example Language: C
int main (int argc, char **argv) { char *items[] = {"boat", "car", "truck", "train"}; }int index = GetUntrustedOffset(); printf("You selected %s\n", items[index-1]); The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126). Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship
This weakness can precede uncontrolled memory allocation (CWE-789) in languages that automatically expand an array when an index is used that is larger than the size of the array, such as JavaScript.
Theoretical
An improperly validated array index might lead directly to the always-incorrect behavior of "access of array using out-of-bounds index."
CWE-459: Incomplete Cleanup
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not properly "clean up" and remove temporary or supporting resources after they have been used.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 Stream resources in a Java application should be released in a finally block, otherwise an exception thrown before the call to close() would result in an unreleased I/O resource. In the example below, the close() method is called in the try block (incorrect). (bad code)
Example Language: Java
try {
InputStream is = new FileInputStream(path); } catch (Throwable t) {byte b[] = new byte[is.available()]; is.read(b); is.close(); log.error("Something bad happened: " + t.getMessage()); }Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Relationship
CWE-459 is a child of CWE-404 because, while CWE-404 covers any type of improper shutdown or release of a resource, CWE-459 deals specifically with a multi-step shutdown process in which a crucial step for "proper" cleanup is omitted or impossible. That is, CWE-459 deals specifically with a cleanup or shutdown process that does not successfully remove all potentially sensitive data.
Relationship
Overlaps other categories such as permissions and containment. Concept needs further development. This could be primary (e.g. leading to infoleak) or resultant (e.g. resulting from unhandled error conditions or early termination).
CWE-696: Incorrect Behavior Order
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways that may produce resultant weaknesses.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code attempts to validate a given input path by checking it against an allowlist and then return the canonical path. In this specific case, the path is considered valid if it starts with the string "/safe_dir/". (bad code)
Example Language: Java
String path = getInputPath();
if (path.startsWith("/safe_dir/")) { File f = new File(path); }return f.getCanonicalPath(); The problem with the above code is that the validation step occurs before canonicalization occurs. An attacker could provide an input path of "/safe_dir/../" that would pass the validation step. However, the canonicalization process sees the double dot as a traversal to the parent directory and hence when canonicized the path would become just "/". To avoid this problem, validation should occur after canonicalization takes place. In this case canonicalization occurs during the initialization of the File object. The code below fixes the issue. (good code)
Example Language: Java
String path = getInputPath();
File f = new File(path); if (f.getCanonicalPath().startsWith("/safe_dir/")) { return f.getCanonicalPath(); }Example 2 This function prints the contents of a specified file requested by a user. (bad code)
Example Language: PHP
function printFile($username,$filename){
//read file into string $file = file_get_contents($filename); if ($file && isOwnerOf($username,$filename)){ echo $file; }return true; else{ echo 'You are not authorized to view this file'; }return false; This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway. Example 3 Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access. (bad code)
Example Language: Verilog
module foo_bar(data_out, usr_id, data_in, clk, rst_n);
output reg [7:0] data_out; input wire [2:0] usr_id; input wire [7:0] data_in; input wire clk, rst_n; wire grant_access; always @ (posedge clk or negedge rst_n) begin
if (!rst_n)
end
data_out = 0;
else
data_out = (grant_access) ? data_in : data_out;
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0; endmodule This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1. Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below. (good code)
Example Language: Verilog
always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
end
data_out = 0;
else
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
data_out = (grant_access) ? data_in : data_out; endmodule Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-682: Incorrect Calculation
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
When product performs a security-critical calculation incorrectly, it might lead to incorrect resource allocations, incorrect privilege assignments, or failed comparisons among other things. Many of the direct results of an incorrect calculation can lead to even larger problems such as failed protection mechanisms or even arbitrary code execution.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following image processing code allocates a table for images. (bad code)
Example Language: C
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs; ... num_imgs = get_num_imgs(); table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs); ... This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119). Example 2 This code attempts to calculate a football team's average number of yards gained per touchdown. (bad code)
Example Language: Java
...
int touchdowns = team.getTouchdowns(); int yardsGained = team.getTotalYardage(); System.out.println(team.getName() + " averages " + yardsGained / touchdowns + "yards gained for every touchdown scored"); ... The code does not consider the event that the team they are querying has not scored a touchdown, but has gained yardage. In that case, we should expect an ArithmeticException to be thrown by the JVM. This could lead to a loss of availability if our error handling code is not set up correctly. Example 3 This example attempts to calculate the position of the second byte of a pointer. (bad code)
Example Language: C
int *p = x;
char * second_char = (char *)(p + 1); In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Research Gap Weaknesses related to this Pillar appear to be under-studied, especially with respect to classification schemes. Input from academic and other communities could help identify and resolve gaps or organizational difficulties within CWE.
CWE-131: Incorrect Calculation of Buffer Size
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code allocates memory for a maximum number of widgets. It then gets a user-specified number of widgets, making sure that the user does not request too many. It then initializes the elements of the array using InitializeWidget(). Because the number of widgets can vary for each request, the code inserts a NULL pointer to signify the location of the last widget. (bad code)
Example Language: C
int i;
unsigned int numWidgets; Widget **WidgetList; numWidgets = GetUntrustedSizeValue(); if ((numWidgets == 0) || (numWidgets > MAX_NUM_WIDGETS)) { ExitError("Incorrect number of widgets requested!"); }WidgetList = (Widget **)malloc(numWidgets * sizeof(Widget *)); printf("WidgetList ptr=%p\n", WidgetList); for(i=0; i<numWidgets; i++) { WidgetList[i] = InitializeWidget(); }WidgetList[numWidgets] = NULL; showWidgets(WidgetList); However, this code contains an off-by-one calculation error (CWE-193). It allocates exactly enough space to contain the specified number of widgets, but it does not include the space for the NULL pointer. As a result, the allocated buffer is smaller than it is supposed to be (CWE-131). So if the user ever requests MAX_NUM_WIDGETS, there is an out-of-bounds write (CWE-787) when the NULL is assigned. Depending on the environment and compilation settings, this could cause memory corruption. Example 2 The following image processing code allocates a table for images. (bad code)
Example Language: C
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs; ... num_imgs = get_num_imgs(); table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs); ... This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119). Example 3 This example applies an encoding procedure to an input string and stores it into a buffer. (bad code)
Example Language: C
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE); if ( MAX_SIZE <= strlen(user_supplied_string) ){ die("user string too long, die evil hacker!"); }dst_index = 0; for ( i = 0; i < strlen(user_supplied_string); i++ ){ if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&'; }dst_buf[dst_index++] = 'a'; dst_buf[dst_index++] = 'm'; dst_buf[dst_index++] = 'p'; dst_buf[dst_index++] = ';'; else if ('<' == user_supplied_string[i] ){ /* encode to < */ else dst_buf[dst_index++] = user_supplied_string[i]; return dst_buf; The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands. Example 4 The following code is intended to read an incoming packet from a socket and extract one or more headers. (bad code)
Example Language: C
DataPacket *packet;
int numHeaders; PacketHeader *headers; sock=AcceptSocketConnection(); ReadPacket(packet, sock); numHeaders =packet->headers; if (numHeaders > 100) { ExitError("too many headers!"); }headers = malloc(numHeaders * sizeof(PacketHeader); ParsePacketHeaders(packet, headers); The code performs a check to make sure that the packet does not contain too many headers. However, numHeaders is defined as a signed int, so it could be negative. If the incoming packet specifies a value such as -3, then the malloc calculation will generate a negative number (say, -300 if each header can be a maximum of 100 bytes). When this result is provided to malloc(), it is first converted to a size_t type. This conversion then produces a large value such as 4294966996, which may cause malloc() to fail or to allocate an extremely large amount of memory (CWE-195). With the appropriate negative numbers, an attacker could trick malloc() into using a very small positive number, which then allocates a buffer that is much smaller than expected, potentially leading to a buffer overflow. Example 5 The following code attempts to save three different identification numbers into an array. The array is allocated from memory using a call to malloc(). (bad code)
Example Language: C
int *id_sequence;
/* Allocate space for an array of three ids. */ id_sequence = (int*) malloc(3); if (id_sequence == NULL) exit(1); /* Populate the id array. */ id_sequence[0] = 13579; id_sequence[1] = 24680; id_sequence[2] = 97531; The problem with the code above is the value of the size parameter used during the malloc() call. It uses a value of '3' which by definition results in a buffer of three bytes to be created. However the intention was to create a buffer that holds three ints, and in C, each int requires 4 bytes worth of memory, so an array of 12 bytes is needed, 4 bytes for each int. Executing the above code could result in a buffer overflow as 12 bytes of data is being saved into 3 bytes worth of allocated space. The overflow would occur during the assignment of id_sequence[0] and would continue with the assignment of id_sequence[1] and id_sequence[2]. The malloc() call could have used '3*sizeof(int)' as the value for the size parameter in order to allocate the correct amount of space required to store the three ints. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Maintenance This is a broad category. Some examples include:
This level of detail is rarely available in public reports, so it is difficult to find good examples. Maintenance This weakness may be a composite or a chain. It also may contain layering or perspective differences. This issue may be associated with many different types of incorrect calculations (CWE-682), although the integer overflow (CWE-190) is probably the most prevalent. This can be primary to resource consumption problems (CWE-400), including uncontrolled memory allocation (CWE-789). However, its relationship with out-of-bounds buffer access (CWE-119) must also be considered.
|

