Home > CWE List > VIEW SLICE: CWE-868: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version) (4.16) |
|
CWE VIEW: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)
CWE entries in this view (graph) are fully or partially eliminated by following the SEI CERT C++ Coding Standard, as published in 2016. This view is no longer being actively maintained, since it statically represents the coding rules as they were in 2016.
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:
868 - Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 01 - Preprocessor (PRE)
- (869)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
869
(CERT C++ Secure Coding Section 01 - Preprocessor (PRE))
Weaknesses in this category are related to rules in the Preprocessor (PRE) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL)
- (870)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
870
(CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL))
Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 03 - Expressions (EXP)
- (871)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
871
(CERT C++ Secure Coding Section 03 - Expressions (EXP))
Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
NULL Pointer Dereference
- (476)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
871
(CERT C++ Secure Coding Section 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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Incorrect Operator
- (480)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
871
(CERT C++ Secure Coding Section 03 - Expressions (EXP)) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Short Circuit Evaluation
- (768)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
871
(CERT C++ Secure Coding Section 03 - Expressions (EXP)) >
768
(Incorrect Short Circuit Evaluation)
The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 04 - Integers (INT)
- (872)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT))
Weaknesses in this category are related to rules in the Integers (INT) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Improper Validation of Array Index
- (129)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT)) >
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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Integer Overflow or Wraparound
- (190)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 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
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Integer Coercion Error
- (192)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Numeric Truncation Error
- (197)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Input Validation
- (20)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Divide By Zero
- (369)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT)) >
369
(Divide By Zero)
The product divides a value by zero.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Return of Pointer Value Outside of Expected Range
- (466)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT)) >
466
(Return of Pointer Value Outside of Expected Range)
A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Assignment of a Fixed Address to a Pointer
- (587)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Unchecked Input for Loop Condition
- (606)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT)) >
606
(Unchecked Input for Loop Condition)
The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Potentially Dangerous Function
- (676)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 04 - Integers (INT)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Conversion between Numeric Types
- (681)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 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.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Incorrect Calculation
- (682)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
872
(CERT C++ Secure Coding Section 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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
- (873)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
873
(CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP))
Weaknesses in this category are related to rules in the Floating Point Arithmetic (FLP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Divide By Zero
- (369)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
873
(CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) >
369
(Divide By Zero)
The product divides a value by zero.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Conversion between Numeric Types
- (681)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
873
(CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (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.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Incorrect Calculation
- (682)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
873
(CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (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.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Function Call With Incorrect Argument Type
- (686)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
873
(CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) >
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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
- (874)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR))
Weaknesses in this category are related to rules in the Arrays and the STL (ARR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Restriction of Operations within the Bounds of a Memory Buffer
- (119)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (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
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Improper Validation of Array Index
- (129)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (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
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Use of sizeof() on a Pointer Type
- (467)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Pointer Subtraction to Determine Size
- (469)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Initialization
- (665)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) >
665
(Improper Initialization)
The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Buffer Access with Incorrect Length Value
- (805)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
874
(CERT C++ Secure Coding Section 06 - Arrays and the STL (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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
- (875)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 07 - Characters and Strings (STR))
Weaknesses in this category are related to rules in the Characters and Strings (STR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Restriction of Operations within the Bounds of a Memory Buffer
- (119)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
- (120)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 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, leading to a buffer overflow.
Classic Buffer Overflow
Unbounded Transfer
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Null Termination
- (170)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Off-by-one Error
- (193)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) >
193
(Off-by-one Error)
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.
off-by-five
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Addition of Data Structure Sentinel
- (464)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) >
464
(Addition of Data Structure Sentinel)
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Function Call With Incorrect Argument Type
- (686)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) >
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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Incorrect Type Conversion or Cast
- (704)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
- (78)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) >
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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
- (88)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
875
(CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) >
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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 08 - Memory Management (MEM)
- (876)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM))
Weaknesses in this category are related to rules in the Memory Management (MEM) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Restriction of Operations within the Bounds of a Memory Buffer
- (119)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Wrap-around Error
- (128)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
128
(Wrap-around Error)
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Calculation of Buffer Size
- (131)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Integer Overflow or Wraparound
- (190)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 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
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Input Validation
- (20)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Sensitive Information in Resource Not Removed Before Reuse
- (226)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
226
(Sensitive Information in Resource Not Removed Before Reuse)
The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Improper Clearing of Heap Memory Before Release ('Heap Inspection')
- (244)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
244
(Improper Clearing of Heap Memory Before Release ('Heap Inspection'))
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Unchecked Return Value
- (252)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Unchecked Error Condition
- (391)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Resource Shutdown or Release
- (404)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 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.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Double Free
- (415)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
415
(Double Free)
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
Double-free
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Use After Free
- (416)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
NULL Pointer Dereference
- (476)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Exposure of Core Dump File to an Unauthorized Control Sphere
- (528)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
528
(Exposure of Core Dump File to an Unauthorized Control Sphere)
The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Free of Memory not on the Heap
- (590)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 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().
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Sensitive Data Storage in Improperly Locked Memory
- (591)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
591
(Sensitive Data Storage in Improperly Locked Memory)
The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Initialization
- (665)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
665
(Improper Initialization)
The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Function Call With Incorrectly Specified Argument Value
- (687)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
687
(Function Call With Incorrectly Specified Argument Value)
The product calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.
Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.
Unchecked Return Value to NULL Pointer Dereference
- (690)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Check or Handling of Exceptional Conditions
- (703)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
703
(Improper Check or Handling of Exceptional Conditions)
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Check for Unusual or Exceptional Conditions
- (754)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
754
(Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Mismatched Memory Management Routines
- (762)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Allocation of Resources Without Limits or Throttling
- (770)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
770
(Allocation of Resources Without Limits or Throttling)
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Untrusted Pointer Dereference
- (822)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
876
(CERT C++ Secure Coding Section 08 - Memory Management (MEM)) >
822
(Untrusted Pointer Dereference)
The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 09 - Input Output (FIO)
- (877)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO))
Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Restriction of Operations within the Bounds of a Memory Buffer
- (119)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Externally-Controlled Format String
- (134)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
- (22)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
22
(Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Directory traversal
Path traversal
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Handling of Unexpected Data Type
- (241)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 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).
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Default Permissions
- (276)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
276
(Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Execution-Assigned Permissions
- (279)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
279
(Incorrect Execution-Assigned Permissions)
While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- (362)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Time-of-check Time-of-use (TOCTOU) Race Condition
- (367)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
367
(Time-of-check Time-of-use (TOCTOU) Race Condition)
The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state.
TOCTTOU
TOCCTOU
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Path Traversal: '/absolute/pathname/here'
- (37)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
37
(Path Traversal: '/absolute/pathname/here')
The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Creation of Temporary File in Directory with Insecure Permissions
- (379)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
379
(Creation of Temporary File in Directory with Insecure Permissions)
The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Path Traversal: '\absolute\pathname\here'
- (38)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
38
(Path Traversal: '\absolute\pathname\here')
The product accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Path Traversal: 'C:dirname'
- (39)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
39
(Path Traversal: 'C:dirname')
The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Unchecked Error Condition
- (391)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
- (403)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
403
(Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.
File descriptor leak
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Resource Shutdown or Release
- (404)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Resolution of Path Equivalence
- (41)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
41
(Improper Resolution of Path Equivalence)
The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Files or Directories Accessible to External Parties
- (552)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
552
(Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Link Resolution Before File Access ('Link Following')
- (59)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
59
(Improper Link Resolution Before File Access ('Link Following'))
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
insecure temporary file
Zip Slip
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
UNIX Hard Link
- (62)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
62
(UNIX Hard Link)
The product, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Windows Shortcut Following (.LNK)
- (64)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
64
(Windows Shortcut Following (.LNK))
The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
Windows symbolic link following
symlink
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Windows Hard Link
- (65)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
65
(Windows Hard Link)
The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Improper Handling of Windows Device Names
- (67)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Multiple Operations on Resource in Single-Operation Context
- (675)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
675
(Multiple Operations on Resource in Single-Operation Context)
The product performs the same operation on a resource two or more times, when the operation should only be applied once.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Potentially Dangerous Function
- (676)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
External Control of File Name or Path
- (73)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
73
(External Control of File Name or Path)
The product allows user input to control or influence paths or file names that are used in filesystem operations.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Incorrect Permission Assignment for Critical Resource
- (732)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
732
(Incorrect Permission Assignment for Critical Resource)
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Allocation of Resources Without Limits or Throttling
- (770)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
877
(CERT C++ Secure Coding Section 09 - Input Output (FIO)) >
770
(Allocation of Resources Without Limits or Throttling)
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 10 - Environment (ENV)
- (878)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 10 - Environment (ENV))
Weaknesses in this category are related to rules in the Environment (ENV) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Restriction of Operations within the Bounds of a Memory Buffer
- (119)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 10 - Environment (ENV)) >
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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Untrusted Search Path
- (426)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 10 - Environment (ENV)) >
426
(Untrusted Search Path)
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
Untrusted Path
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Duplicate Key in Associative List (Alist)
- (462)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 10 - Environment (ENV)) >
462
(Duplicate Key in Associative List (Alist))
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Incorrect Control Flow Scoping
- (705)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
- (78)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 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
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Reliance on Untrusted Inputs in a Security Decision
- (807)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 10 - Environment (ENV)) >
807
(Reliance on Untrusted Inputs in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
- (88)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
878
(CERT C++ Secure Coding Section 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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 11 - Signals (SIG)
- (879)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
879
(CERT C++ Secure Coding Section 11 - Signals (SIG))
Weaknesses in this category are related to rules in the Signals (SIG) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Signal Handler Use of a Non-reentrant Function
- (479)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
879
(CERT C++ Secure Coding Section 11 - Signals (SIG)) >
479
(Signal Handler Use of a Non-reentrant Function)
The product defines a signal handler that calls a non-reentrant function.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Synchronization
- (662)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
879
(CERT C++ Secure Coding Section 11 - Signals (SIG)) >
662
(Improper Synchronization)
The product utilizes multiple threads or processes 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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
- (880)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR))
Weaknesses in this category are related to rules in the Exceptions and Error Handling (ERR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Generation of Error Message Containing Sensitive Information
- (209)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
209
(Generation of Error Message Containing Sensitive Information)
The product generates an error message that includes sensitive information about its environment, users, or associated data.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Detection of Error Condition Without Action
- (390)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
390
(Detection of Error Condition Without Action)
The product detects a specific error, but takes no actions to handle the error.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Unchecked Error Condition
- (391)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Cleanup on Thrown Exception
- (460)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
460
(Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Exposure of Sensitive System Information to an Unauthorized Control Sphere
- (497)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
497
(Exposure of Sensitive System Information to an Unauthorized Control Sphere)
The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Standardized Error Handling Mechanism
- (544)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
544
(Missing Standardized Error Handling Mechanism)
The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Check or Handling of Exceptional Conditions
- (703)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
703
(Improper Check or Handling of Exceptional Conditions)
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Incorrect Control Flow Scoping
- (705)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Check for Unusual or Exceptional Conditions
- (754)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
754
(Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Handling of Exceptional Conditions
- (755)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
880
(CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) >
755
(Improper Handling of Exceptional Conditions)
The product does not handle or incorrectly handles an exceptional condition.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP)
- (881)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
881
(CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP))
Weaknesses in this category are related to rules in the Object Oriented Programming (OOP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 14 - Concurrency (CON)
- (882)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
882
(CERT C++ Secure Coding Section 14 - Concurrency (CON))
Weaknesses in this category are related to rules in the Concurrency (CON) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- (362)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
882
(CERT C++ Secure Coding Section 14 - Concurrency (CON)) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Race Condition within a Thread
- (366)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
882
(CERT C++ Secure Coding Section 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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Resource Shutdown or Release
- (404)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
882
(CERT C++ Secure Coding Section 14 - Concurrency (CON)) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Exposure of Data Element to Wrong Session
- (488)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
882
(CERT C++ Secure Coding Section 14 - Concurrency (CON)) >
488
(Exposure of Data Element to Wrong Session)
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Release of Resource after Effective Lifetime
- (772)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
882
(CERT C++ Secure Coding Section 14 - Concurrency (CON)) >
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.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
- (883)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC))
Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Encoding or Escaping of Output
- (116)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
116
(Improper Encoding or Escaping of Output)
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
Output Sanitization
Output Validation
Output Encoding
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Compiler Removal of Code to Clear Buffers
- (14)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
14
(Compiler Removal of Code to Clear Buffers)
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Improper Handling of Unicode Encoding
- (176)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
176
(Improper Handling of Unicode Encoding)
The product does not properly handle when an input contains Unicode encoding.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Input Validation
- (20)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
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.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Use of a Broken or Risky Cryptographic Algorithm
- (327)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Use of Insufficiently Random Values
- (330)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - 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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Incorrect Operator
- (480)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Comparing instead of Assigning
- (482)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
482
(Comparing instead of Assigning)
The code uses an operator for comparison when the intention was to perform an assignment.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Dead Code
- (561)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
561
(Dead Code)
The product contains dead code, which can never be executed.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Assignment to Variable without Use
- (563)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
563
(Assignment to Variable without Use)
The variable's value is assigned but never used, making it a dead store.
Unused Variable
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Expression is Always False
- (570)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
570
(Expression is Always False)
The product contains an expression that will always evaluate to false.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Expression is Always True
- (571)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
571
(Expression is Always True)
The product contains an expression that will always evaluate to true.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Incorrect Comparison
- (697)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
697
(Incorrect Comparison)
The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Incorrect Type Conversion or Cast
- (704)
868
(Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) >
883
(CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
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-464: Addition of Data Structure Sentinel
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 accidental addition of a data-structure sentinel can cause serious programming logic problems.
Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels.
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" (CWE-1000)
Relevant to the view "Software Development" (CWE-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.
Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 The following example assigns some character values to a list of characters and prints them each individually, and then as a string. The third character value is intended to be an integer taken from user input and converted to an int. (bad code)
Example Language: C
char *foo;
foo=malloc(sizeof(char)*5); foo[0]='a'; foo[1]='a'; foo[2]=atoi(getc(stdin)); foo[3]='c'; foo[4]='\0' printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3],foo[4]); printf("%s\n",foo); The first print statement will print each character separated by a space. However, if a non-integer is read from stdin by getc, then atoi will not make a conversion and return 0. When foo is printed as a string, the 0 at character foo[2] will act as a NULL terminator and foo[3] will never be printed.
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-770: Allocation of Resources Without Limits or Throttling
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 a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service. 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" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-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.
Languages Class: Not Language-Specific (Often Prevalent) 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. Example 2 In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket. (bad code)
Example Language: C
int writeDataFromSocketToFile(char *host, int port)
{ char filename[FILENAME_SIZE]; char buffer[BUFFER_SIZE]; int socket = openSocketConnection(host, port); if (socket < 0) { printf("Unable to open socket connection"); }return(FAIL); if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) { if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0)) }break;
closeFile(); closeSocket(socket); This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service. Example 3 In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array. (bad code)
Example Language: C
/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */ int processMessage(char **message) { char *body;
int length = getMessageLength(message[0]); if (length > 0) { body = &message[1][0]; }processMessageBody(body); return(SUCCESS); else { printf("Unable to process message; invalid message length"); }return(FAIL); This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code. (good code)
Example Language: C
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...} Example 4 In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket. (bad code)
Example Language: Java
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0; boolean hasConnections = true; while (hasConnections) { Socket client = serverSocket.accept(); }Thread t = new Thread(new ClientSocketThread(client)); t.setName(client.getInetAddress().getHostName() + ":" + counter++); t.start(); serverSocket.close(); } catch (IOException ex) {...} In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources. The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated. (good code)
Example Language: Java
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10; ... public void acceptConnections() { try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0; boolean hasConnections = true; while (hasConnections) { hasConnections = checkForMoreConnections(); }Socket client = serverSocket.accept(); Thread t = new Thread(new ClientSocketThread(client)); t.setName(client.getInetAddress().getHostName() + ":" + counter++); ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS); pool.execute(t); serverSocket.close(); } catch (IOException ex) {...} Example 5 An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.
Example 6 Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory. (bad code)
Example Language: C
bar connection() {
foo = malloc(1024); }return foo; endConnection(bar foo) { free(foo); }int main() { while(1) { }foo=connection(); }endConnection(foo)
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 entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).
Theoretical
Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
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" (CWE-1000)
Relevant to the view "Software Development" (CWE-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.
Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) C# (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) 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-563: Assignment to Variable without Use
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
After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.
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" (CWE-1000)
Relevant to the view "Software Development" (CWE-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.
Example 1 The following code excerpt assigns to the variable r and then overwrites the value without using it. (bad code)
Example Language: C
r = getName();
r = getNewBuffer(buf);
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" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-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.
Languages C (Often Prevalent) C++ (Often Prevalent) Class: Assembly (Undetermined Prevalence) 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.
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 FilterThe 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, leading to a buffer overflow.
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 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.
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" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Relevant to the view "Seven Pernicious Kingdoms" (CWE-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.
Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) 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. |