CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-734: Weaknesses Addressed by the CERT C Secure Coding Standard (2008) (4.15)  
ID

CWE VIEW: Weaknesses Addressed by the CERT C Secure Coding Standard (2008)

View ID: 734
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Type: Graph
Downloads: Booklet | CSV | XML
+ Objective
CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the book "The CERT C Secure Coding Standard" published in 2008. This view is considered obsolete, as a newer version of the coding standard is available. This view statically represents the coding rules as they were in 2008.
+ Audience
StakeholderDescription
Software DevelopersBy following the CERT C Secure Coding Standard, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Product CustomersIf a software developer claims to be following the CERT C Secure Coding standard, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
EducatorsEducators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.
+ Relationships
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:
734 - Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 2 - Preprocessor (PRE) - (735)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 735 (CERT C Secure Coding Standard (2008) Chapter 2 - Preprocessor (PRE))
Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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 Provision of Specified Functionality - (684)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 735 (CERT C Secure Coding Standard (2008) Chapter 2 - Preprocessor (PRE)) > 684 (Incorrect Provision of Specified Functionality)
The code does not function according to its published specifications, potentially leading to incorrect usage.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL) - (736)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 736 (CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL))
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) chapter of the CERT C Secure Coding Standard (2008).
*BaseBase - 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 Hard-coded, Security-relevant Constants - (547)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 736 (CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)) > 547 (Use of Hard-coded, Security-relevant Constants)
The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.
*BaseBase - 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.Function Call with Incorrectly Specified Arguments - (628)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 736 (CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 736 (CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)) > 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP) - (737)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP))
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) chapter of the CERT C Secure Coding Standard (2008).
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 467 (Use of sizeof() on a Pointer Type)
The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated.
*BaseBase - 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 Pointer Scaling - (468)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 468 (Incorrect Pointer Scaling)
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 476 (NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL.NPDnull derefNPEnil pointer dereference
*BaseBase - 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.Function Call with Incorrectly Specified Arguments - (628)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 704 (Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
*BaseBase - 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.Operator Precedence Logic Error - (783)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 783 (Operator Precedence Logic Error)
The product uses an expression in which operator precedence causes incorrect logic to be used.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT) - (738)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT))
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) chapter of the CERT C Secure Coding Standard (2008).
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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 indexindex-out-of-rangearray index underflow
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.OverflowWraparoundwrap, wrap-around, wrap around
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)) > 369 (Divide By Zero)
The product divides a value by zero.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
*PillarPillar - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP) - (739)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 739 (CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP))
Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) chapter of the CERT C Secure Coding Standard (2008).
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 739 (CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)) > 369 (Divide By Zero)
The product divides a value by zero.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 739 (CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)) > 681 (Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
*PillarPillar - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 739 (CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)) > 682 (Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 739 (CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR) - (740)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR))
Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 129 (Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 467 (Use of sizeof() on a Pointer Type)
The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 469 (Use of Pointer Subtraction to Determine Size)
The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 805 (Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR) - (741)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR))
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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 Overflowbuffer overrunmemory safety
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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 OverflowUnbounded Transfer
*BaseBase - 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 Multi-Byte String Length - (135)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)) > 135 (Incorrect Calculation of Multi-Byte String Length)
The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)) > 464 (Addition of Data Structure Sentinel)
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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 injectionShell metacharactersOS Command Injection
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM) - (742)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM))
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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 Overflowbuffer overrunmemory safety
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.OverflowWraparoundwrap, wrap-around, wrap around
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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 pointerUAFUse-After-Free
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)) > 476 (NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL.NPDnull derefNPEnil pointer dereference
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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().
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*BaseBase - 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.Function Call with Incorrectly Specified Arguments - (628)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO) - (743)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO))
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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 Overflowbuffer overrunmemory safety
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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 traversalPath traversal
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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).
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 276 (Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a code sequence that can run concurrently with other code, and the code sequence 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 that is operating concurrently.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.TOCTTOUTOCCTOU
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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 fileZip Slip
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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 followingsymlink
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 686 (Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV) - (744)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV))
Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - 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 Overflowbuffer overrunmemory safety
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - 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
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - 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 injectionShell metacharactersOS Command Injection
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 12 - Signals (SIG) - (745)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 745 (CERT C Secure Coding Standard (2008) Chapter 12 - Signals (SIG))
Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) chapter of the CERT C Secure Coding Standard (2008).
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 745 (CERT C Secure Coding Standard (2008) Chapter 12 - Signals (SIG)) > 479 (Signal Handler Use of a Non-reentrant Function)
The product defines a signal handler that calls a non-reentrant function.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 745 (CERT C Secure Coding Standard (2008) Chapter 12 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR) - (746)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 746 (CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR))
Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) chapter of the CERT C Secure Coding Standard (2008).
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 746 (CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)) > 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 746 (CERT C Secure Coding Standard (2008) Chapter 13 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 746 (CERT C Secure Coding Standard (2008) Chapter 13 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 746 (CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)) > 676 (Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 746 (CERT C Secure Coding Standard (2008) Chapter 13 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC) - (747)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC))
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) chapter of the CERT C Secure Coding Standard (2008).
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - 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."
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 176 (Improper Handling of Unicode Encoding)
The product does not properly handle when an input contains Unicode encoding.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - 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.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 480 (Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 482 (Comparing instead of Assigning)
The code uses an operator for comparison when the intention was to perform an assignment.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 561 (Dead Code)
The product contains dead code, which can never be executed.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 563 (Assignment to Variable without Use)
The variable's value is assigned but never used, making it a dead store.Unused Variable
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 570 (Expression is Always False)
The product contains an expression that will always evaluate to false.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)) > 571 (Expression is Always True)
The product contains an expression that will always evaluate to true.
*PillarPillar - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - 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.
*ClassClass - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 747 (CERT C Secure Coding Standard (2008) Chapter 14 - 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CERT C Secure Coding Standard (2008) Appendix - POSIX (POS) - (748)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS))
Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) appendix of the CERT C Secure Coding Standard (2008).
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 170 (Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
*BaseBase - 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 Inherently Dangerous Function - (242)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 242 (Use of Inherently Dangerous Function)
The product calls a function that can never be guaranteed to work safely.
*BaseBase - 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.Least Privilege Violation - (272)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
*BaseBase - 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 Check for Dropped Privileges - (273)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 273 (Improper Check for Dropped Privileges)
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
*BaseBase - 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 Enabling Link Following - (363)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 363 (Race Condition Enabling Link Following)
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 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.
*BaseBase - 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 Stack Variable Address - (562)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 562 (Return of Stack Variable Address)
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
*BaseBase - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 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 fileZip Slip
*ClassClass - 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 Locking - (667)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 667 (Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
*VariantVariant - 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)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 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.
*ClassClass - 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 Behavior Order - (696)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 696 (Incorrect Behavior Order)
The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.
+ Notes

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.
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses91out of 939
Categories14out of 374
Views0out of 50
Total105out of1363
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, References
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2020-02-24CWE Content TeamMITRE
updated View_Audience
2021-03-15CWE Content TeamMITRE
updated Description, Maintenance_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08Weaknesses Addressed by the CERT C Secure Coding Standard
2019-01-03Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)

View Components

A | 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

Weakness ID: 464
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - 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.
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


+ Description
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
+ Extended Description
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.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

Generally this error will cause the data structure to not work properly by truncating the data.
+ Potential Mitigations

Phases: Implementation; Architecture and Design

Encapsulate the user from interacting with data sentinels. Validate user input to verify that sentinels are not present.

Phase: Implementation

Proper error checking can reduce the risk of inadvertently introducing sentinel values into data. For example, if a parsing function fails or encounters an error, it might return a value that is the same as the sentinel.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. This is not a complete solution.

Phase: Operation

Use OS-level preventative functionality. This is not a complete solution.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
PeerOfBaseBase - 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.170Improper Null Termination
PeerOfBaseBase - 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.463Deletion of Data Structure Sentinel
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis 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)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

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


+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAddition of data-structure sentinel
CERT C Secure CodingSTR03-CDo not inadvertently truncate a null-terminated byte string
CERT C Secure CodingSTR06-CDo not assume that strtok() leaves the parse string unchanged
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Addition of Data-structure Sentinel

CWE-587: Assignment of a Fixed Address to a Pointer

Weakness ID: 587
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: VariantVariant - 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.
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


+ Description
The product sets a pointer to a specific address other than NULL or 0.
+ Extended Description
Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

If one executes code at a known location, an attacker might be able to inject code there beforehand.
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Reduce Maintainability; Reduce Reliability

If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.
Confidentiality
Integrity

Technical Impact: Read Memory; Modify Memory

The data at a known pointer location can be easily read or influenced by an attacker.
+ Potential Mitigations

Phase: Implementation

Never set a pointer to a fixed address.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.344Use of Invariant Value in Dynamically Changing Context
ChildOfClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis 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)

+ Demonstrative Examples

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


+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingINT36-CImpreciseConverting a pointer to integer or integer to pointer
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Common_Consequences, Weakness_Ordinalities
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-563: Assignment to Variable without Use

Weakness ID: 563
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - 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.
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


+ Description
The variable's value is assigned but never used, making it a dead store.
+ Extended Description
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.
+ Alternate Terms
Unused Variable
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.
+ Potential Mitigations

Phase: Implementation

Remove unused variables from the code.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1164Irrelevant Code
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Demonstrative Examples

Example 1

The following code excerpt assigns to the variable r and then overwrites the value without using it.

(bad code)
Example Language:
r = getName();
r = getNewBuffer(buf);

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1186SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
SEI CERT Perl Coding StandardMSC01-PLImpreciseDetect and remove unused variables
Software Fault PatternsSFP2Unused Entities
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Alternate_Terms, Name, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2014-06-23Unused Variable
2017-11-08Assignment to Variable without Use ('Unused Variable')

CWE-805: Buffer Access with Incorrect Length Value

Weakness ID: 805
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - 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.
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


+ Description
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.
+ Extended Description
When the length value exceeds the size of the destination, a buffer overflow could occur.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Read Memory; Modify Memory; Execute Unauthorized Code or Commands

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

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

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

Phase: Requirements

Strategy: Language Selection

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

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

Note: This is not a complete solution, since many buffer overflows are not related to strings.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Implementation

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

  • Double check that the buffer is as large as specified.
  • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
  • Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
  • If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phase: Architecture and Design

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

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333].

Phase: Operation

Strategy: Environment Hardening

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

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

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - 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.806Buffer Access Using Size of Source Buffer
CanFollowBaseBase - 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.130Improper Handling of Length Parameter Inconsistency
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1218Memory Buffer Errors
Section HelpThis 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 "CISQ Quality Measures (2020)" (CWE-1305)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "CISQ Data Protection Measures" (CWE-1340)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis 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)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

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:
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:
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:
...
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:
...
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:
#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:
...
// 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:
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.


+ Observed Examples
ReferenceDescription
Chain: large length value causes buffer over-read (CWE-126)
Use of packet length field to make a calculation, then copy into a fixed-size buffer
Chain: retrieval of length value from an uninitialized memory location
Crafted length value in document reader leads to buffer overflow
SSL server overflow when the sum of multiple length fields exceeds a given value
Language interpreter API function doesn't validate length argument, leading to information exposure
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Effectiveness: Moderate

Note: Without visibility into the code, black box methods may not be able to sufficiently distinguish this weakness from others, requiring manual methods to diagnose the underlying problem.

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.
+ Affected Resources
  • Memory
+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.740CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingARR38-CImpreciseGuarantee that library functions do not form invalid pointers
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Why ACLs Are Important" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-741] Jason Lam. "Top 25 Series - Rank 12 - Buffer Access with Incorrect Length Value". SANS Software Security Institute. 2010-03-11. <https://web.archive.org/web/20100316043717/http://blogs.sans.org:80/appsecstreetfighter/2010/03/11/top-25-series-rank-12-buffer-access-with-incorrect-length-value/>. URL validated: 2023-04-07.
[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. URL validated: 2023-04-07.
[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2010-01-15
(CWE 1.8, 2010-02-16)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description, Detection_Factors, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Weakness ID: 120
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: BaseBase - 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.
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


+ Description
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.
+ Extended Description
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.
+ Alternate Terms
Classic Buffer Overflow:
This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.
Unbounded Transfer
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

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

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

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

Phase: Requirements

Strategy: Language Selection

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

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

Note: This is not a complete solution, since many buffer overflows are not related to strings.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Implementation

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

  • Double check that your buffer is as large as you specify.
  • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
  • Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
  • If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Architecture and Design

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

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Operation

Strategy: Environment Hardening

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

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

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phases: Build and Compilation; Operation

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

Phase: Implementation

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

Effectiveness: Moderate

Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - 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.785Use of Path Manipulation Function without Maximum-sized Buffer
CanFollowBaseBase - 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.170Improper Null Termination
CanFollowVariantVariant - 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.231Improper Handling of Extra Values
CanFollowVariantVariant - 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.416Use After Free
CanFollowVariantVariant - 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.456Missing Initialization of a Variable
CanPrecedeBaseBase - 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.123Write-what-where Condition
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1218Memory Buffer Errors
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "CISQ Quality Measures (2020)" (CWE-1305)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "CISQ Data Protection Measures" (CWE-1340)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis 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)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

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:
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:
void manipulate_string(char * string){
char buf[24];
strcpy(buf, string);
...
}

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.


Example 3

The code below calls the gets() function to read in data from the command line.

(bad code)
Example Language:
char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.


Example 4

In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file.

(bad code)
Example Language:
...
struct hostent *clienthp;
char hostname[MAX_LEN];

// create server socket, bind to server address and listen on socket
...

// accept client connections and process requests
int count = 0;
for (count = 0; count < MAX_CONNECTIONS; count++) {

int clientlen = sizeof(struct sockaddr_in);
int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen);

if (clientsocket >= 0) {
clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name);
logOutput("Accepted client connection from host ", hostname);

// process client request
...
close(clientsocket);
}
}
close(serversocket);

...

However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.


+ Observed Examples
ReferenceDescription
buffer overflow using command with long argument
buffer overflow in local program using long environment variable
buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Functional Areas
  • Memory Management
+ Affected Resources
  • Memory
+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.726OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Frequent Misuse

Rationale:

There are some indications that this CWE ID might be misused and selected simply because it mentions "buffer overflow" - an increasingly vague term. This CWE entry is only appropriate for "Buffer Copy" operations (not buffer reads), in which where there is no "Checking [the] Size of Input", and (by implication of the copy) writing past the end of the buffer.

Comments:

If the vulnerability being analyzed involves out-of-bounds reads, then consider CWE-125 or descendants. For root cause analysis: if there is any input validation, consider children of CWE-20 such as CWE-1284. If there is a calculation error for buffer sizes, consider CWE-131 or similar.
+ Notes

Relationship

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

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnbounded Transfer ('classic overflow')
7 Pernicious KingdomsBuffer Overflow
CLASPBuffer overflow
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A5CWE More SpecificBuffer Overflows
CERT C Secure CodingSTR31-CExactGuarantee that storage for strings has sufficient space for character data and the null terminator
WASC7Buffer Overflow
Software Fault PatternsSFP8Faulty Buffer Access
OMG ASCSMASCSM-CWE-120
OMG ASCRMASCRM-CWE-120
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. URL validated: 2023-04-07.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-74] Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10CWE Content TeamMITRE
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24CWE Content TeamMITRE
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Relationships
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2020-12-10CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Potential_Mitigations
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unbounded Transfer ('Classic Buffer Overflow')

CWE CATEGORY: CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)

Category ID: 748
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) appendix of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
HasMemberBaseBase - 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.170Improper Null Termination
HasMemberBaseBase - 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.242Use of Inherently Dangerous Function
HasMemberBaseBase - 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.272Least Privilege Violation
HasMemberBaseBase - 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.273Improper Check for Dropped Privileges
HasMemberBaseBase - 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.363Race Condition Enabling Link Following
HasMemberBaseBase - 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.366Race Condition within a Thread
HasMemberBaseBase - 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.562Return of Stack Variable Address
HasMemberClassClass - 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.667Improper Locking
HasMemberVariantVariant - 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.686Function Call With Incorrect Argument Type
HasMemberClassClass - 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.696Incorrect Behavior Order
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-59 POS01-C Check for the existence of links when dealing with files
  • CWE-170 POS30-C Use the readlink() function properly
  • CWE-242 POS33-C Do not use vfork()
  • CWE-272 POS02-C Follow the principle of least privilege
  • CWE-273 POS37-C Ensure that privilege relinquishment is successful
  • CWE-363 POS35-C Avoid race conditions while checking for the existence of a symbolic link
  • CWE-366 POS00-C Avoid race conditions with multiple threads
  • CWE-562 POS34-C Do not call putenv() with a pointer to an automatic variable as the argument
  • CWE-667 POS31-C Do not unlock or destroy another thread's mutex
  • CWE-686 POS34-C Do not call putenv() with a pointer to an automatic variable as the argument
  • CWE-696 POS36-C Observe correct revocation order while relinquishing privileges
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References, Relationship_Notes, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 50 - POSIX (POS)
2019-01-03CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)

Category ID: 743
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
HasMemberVariantVariant - 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.37Path Traversal: '/absolute/pathname/here'
HasMemberVariantVariant - 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.38Path Traversal: '\absolute\pathname\here'
HasMemberVariantVariant - 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.39Path Traversal: 'C:dirname'
HasMemberBaseBase - 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.41Improper Resolution of Path Equivalence
HasMemberBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
HasMemberVariantVariant - 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.62UNIX Hard Link
HasMemberVariantVariant - 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.64Windows Shortcut Following (.LNK)
HasMemberVariantVariant - 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.65Windows Hard Link
HasMemberVariantVariant - 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.67Improper Handling of Windows Device Names
HasMemberClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberBaseBase - 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.134Use of Externally-Controlled Format String
HasMemberBaseBase - 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.241Improper Handling of Unexpected Data Type
HasMemberBaseBase - 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.276Incorrect Default Permissions
HasMemberVariantVariant - 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.279Incorrect Execution-Assigned Permissions
HasMemberClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
HasMemberBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
HasMemberBaseBase - 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.379Creation of Temporary File in Directory with Insecure Permissions
HasMemberBaseBase - 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.391Unchecked Error Condition
HasMemberBaseBase - 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.403Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
HasMemberClassClass - 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.404Improper Resource Shutdown or Release
HasMemberBaseBase - 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.552Files or Directories Accessible to External Parties
HasMemberClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
HasMemberBaseBase - 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.676Use of Potentially Dangerous Function
HasMemberVariantVariant - 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.686Function Call With Incorrect Argument Type
HasMemberClassClass - 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.732Incorrect Permission Assignment for Critical Resource
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-22 FIO02-C Canonicalize path names originating from untrusted sources
  • CWE-37 FIO05-C Identify files using multiple file attributes
  • CWE-38 FIO05-C Identify files using multiple file attributes
  • CWE-39 FIO05-C Identify files using multiple file attributes
  • CWE-41 FIO02-C Canonicalize path names originating from untrusted sources
  • CWE-59 FIO02-C Canonicalize path names originating from untrusted sources
  • CWE-62 FIO05-C Identify files using multiple file attributes
  • CWE-64 FIO05-C Identify files using multiple file attributes
  • CWE-65 FIO05-C Identify files using multiple file attributes
  • CWE-67 FIO32-C Do not perform operations on devices that are only appropriate for files
  • CWE-119 FIO37-C Do not assume character data has been read
  • CWE-134 FIO30-C Exclude user input from format strings
  • CWE-134 FIO30-C Exclude user input from format strings
  • CWE-241 FIO37-C Do not assume character data has been read
  • CWE-276 FIO06-C Create files with appropriate access permissions
  • CWE-279 FIO06-C Create files with appropriate access permissions
  • CWE-362 FIO31-C Do not simultaneously open the same file multiple times
  • CWE-367 FIO01-C Be careful using functions that use file names for identification
  • CWE-379 FIO15-C Ensure that file operations are performed in a secure directory
  • CWE-379 FIO43-C Do not create temporary files in shared directories
  • CWE-391 FIO04-C Detect and handle input and output errors
  • CWE-391 FIO33-C Detect and handle input output errors resulting in undefined behavior
  • CWE-403 FIO42-C Ensure files are properly closed when they are no longer needed
  • CWE-404 FIO42-C Ensure files are properly closed when they are no longer needed
  • CWE-552 FIO15-C Ensure that file operations are performed in a secure directory
  • CWE-675 FIO31-C Do not simultaneously open the same file multiple times
  • CWE-676 FIO01-C Be careful using functions that use file names for identification
  • CWE-686 FIO00-C Take care when creating format strings
  • CWE-732 FIO06-C Create files with appropriate access permissions
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-09-13CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 09 - Input Output (FIO)
2019-01-03CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)

Category ID: 744
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
HasMemberBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
HasMemberClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberBaseBase - 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.426Untrusted Search Path
HasMemberVariantVariant - 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.462Duplicate Key in Associative List (Alist)
HasMemberClassClass - 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.705Incorrect Control Flow Scoping
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-78 ENV03-C Sanitize the environment when invoking external programs
  • CWE-78 ENV04-C Do not call system() if you do not need a command processor
  • CWE-88 ENV03-C Sanitize the environment when invoking external programs
  • CWE-88 ENV04-C Do not call system() if you do not need a command processor
  • CWE-119 ENV01-C Do not make assumptions about the size of an environment variable
  • CWE-426 ENV03-C Sanitize the environment when invoking external programs
  • CWE-462 ENV02-C Beware of multiple environment variables with the same effective name
  • CWE-705 ENV32-C All atexit handlers must return normally
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 10 - Environment (ENV)
2019-01-03CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 12 - Signals (SIG)

Category ID: 745
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberVariantVariant - 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.479Signal Handler Use of a Non-reentrant Function
HasMemberClassClass - 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.662Improper Synchronization
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-432 SIG00-C Mask signals handled by noninterruptible signal handlers
  • CWE-479 SIG30-C Call only asynchronous-safe functions within signal handlers
  • CWE-479 SIG32-C Do not call longjmp() from inside a signal handler
  • CWE-479 SIG33-C Do not recursively invoke the raise() function
  • CWE-479 SIG34-C Do not call signal() from within interruptible signal handlers
  • CWE-662 SIG00-C Mask signals handled by noninterruptible signal handlers
  • CWE-662 SIG31-C Do not access or modify shared objects in signal handlers
  • CWE-828 SIG31-C Do not access or modify shared objects in signal handlers
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 11 - Signals (SIG)
2019-01-03CERT C Secure Coding (2008 Version) Section 11 - Signals (SIG)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)

Category ID: 746
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberClassClass - 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.20Improper Input Validation
HasMemberBaseBase - 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.391Unchecked Error Condition
HasMemberBaseBase - 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.544Missing Standardized Error Handling Mechanism
HasMemberBaseBase - 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.676Use of Potentially Dangerous Function
HasMemberClassClass - 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.705Incorrect Control Flow Scoping
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-20 ERR07-C Prefer functions that support error checking over equivalent functions that don't
  • CWE-391 ERR00-C Adopt and implement a consistent and comprehensive error-handling policy
  • CWE-544 ERR00-C Adopt and implement a consistent and comprehensive error-handling policy
  • CWE-676 ERR07-C Prefer functions that support error checking over equivalent functions that don't
  • CWE-705 ERR04-C Choose an appropriate termination strategy
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 12 - Error Handling (ERR)
2019-01-03CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)

Category ID: 747
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberVariantVariant - 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.14Compiler Removal of Code to Clear Buffers
HasMemberClassClass - 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.20Improper Input Validation
HasMemberVariantVariant - 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.176Improper Handling of Unicode Encoding
HasMemberClassClass - 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.330Use of Insufficiently Random Values
HasMemberBaseBase - 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.480Use of Incorrect Operator
HasMemberVariantVariant - 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.482Comparing instead of Assigning
HasMemberBaseBase - 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.561Dead Code
HasMemberBaseBase - 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.563Assignment to Variable without Use
HasMemberBaseBase - 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.570Expression is Always False
HasMemberBaseBase - 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.571Expression is Always True
HasMemberPillarPillar - 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.697Incorrect Comparison
HasMemberClassClass - 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.704Incorrect Type Conversion or Cast
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-14 MSC06-C Be aware of compiler optimization when dealing with sensitive data
  • CWE-20 MSC08-C Library functions should validate their parameters
  • CWE-176 MSC10-C Character Encoding - UTF8 Related Issues
  • CWE-330 MSC30-C Do not use the rand() function for generating pseudorandom numbers
  • CWE-480 MSC02-C Avoid errors of omission
  • CWE-480 MSC03-C Avoid errors of addition
  • CWE-482 MSC02-C Avoid errors of omission
  • CWE-561 MSC07-C Detect and remove dead code
  • CWE-563 MSC00-C Compile cleanly at high warning levels
  • CWE-570 MSC00-C Compile cleanly at high warning levels
  • CWE-571 MSC00-C Compile cleanly at high warning levels
  • CWE-697 MSC31-C Ensure that return values are compared against the proper type
  • CWE-704 MSC31-C Ensure that return values are compared against the proper type
  • CWE-758 MSC14-C Do not introduce unnecessary platform dependencies
  • CWE-758 MSC15-C Do not depend on undefined behavior
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 49 - Miscellaneous (MSC)
2019-01-03CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 2 - Preprocessor (PRE)

Category ID: 735
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberClassClass - 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.684Incorrect Provision of Specified Functionality
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-684 PRE09-C Do not replace secure functions with less secure functions
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 01 - Preprocessor (PRE)
2019-01-03CERT C Secure Coding (2008 Version) Section 01 - Preprocessor (PRE)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)

Category ID: 736
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberBaseBase - 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.547Use of Hard-coded, Security-relevant Constants
HasMemberBaseBase - 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.628Function Call with Incorrectly Specified Arguments
HasMemberVariantVariant - 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.686Function Call With Incorrect Argument Type
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-547 DCL06-C Use meaningful symbolic constants to represent literal values in program logic
  • CWE-628 DCL10-C Maintain the contract between the writer and caller of variadic functions
  • CWE-686 DCL35-C Do not invoke a function using a type that does not match the function definition
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 02 - Declarations and Initialization (DCL)
2019-01-03CERT C Secure Coding (2008 Version) Section 02 - Declarations and Initialization (DCL)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)

Category ID: 737
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberVariantVariant - 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.467Use of sizeof() on a Pointer Type
HasMemberBaseBase - 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.468Incorrect Pointer Scaling
HasMemberBaseBase - 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.476NULL Pointer Dereference
HasMemberBaseBase - 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.628Function Call with Incorrectly Specified Arguments
HasMemberClassClass - 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.704Incorrect Type Conversion or Cast
HasMemberBaseBase - 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.783Operator Precedence Logic Error
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-467 EXP01-C Do not take the size of a pointer to determine the size of the pointed-to type
  • CWE-468 EXP08-C Ensure pointer arithmetic is used correctly
  • CWE-476 EXP34-C Ensure a null pointer is not dereferenced
  • CWE-628 EXP37-C Call functions with the arguments intended by the API
  • CWE-704 EXP05-C Do not cast away a const qualification
  • CWE-783 EXP00-C Use parentheses for precedence of operation
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-07-27CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 03 - Expressions (EXP)
2019-01-03CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)

Category ID: 738
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberClassClass - 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.20Improper Input Validation
HasMemberVariantVariant - 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.129Improper Validation of Array Index
HasMemberBaseBase - 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.190Integer Overflow or Wraparound
HasMemberVariantVariant - 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.192Integer Coercion Error
HasMemberBaseBase - 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.197Numeric Truncation Error
HasMemberBaseBase - 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.369Divide By Zero
HasMemberBaseBase - 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.466Return of Pointer Value Outside of Expected Range
HasMemberVariantVariant - 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.587Assignment of a Fixed Address to a Pointer
HasMemberBaseBase - 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.606Unchecked Input for Loop Condition
HasMemberBaseBase - 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.676Use of Potentially Dangerous Function
HasMemberBaseBase - 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.681Incorrect Conversion between Numeric Types
HasMemberPillarPillar - 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.682Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-20 INT06-C Use strtol() or a related function to convert a string token to an integer
  • CWE-129 INT32-C Ensure that operations on signed integers do not result in overflow
  • CWE-190 INT03-C Use a secure integer library
  • CWE-190 INT30-C Ensure that unsigned integer operations do not wrap
  • CWE-190 INT32-C Ensure that operations on signed integers do not result in overflow
  • CWE-190 INT35-C Evaluate integer expressions in a larger size before comparing or assigning to that size
  • CWE-192 INT02-C Understand integer conversion rules
  • CWE-192 INT05-C Do not use input functions to convert character data if they cannot handle all possible inputs
  • CWE-192 INT31-C Ensure that integer conversions do not result in lost or misinterpreted data
  • CWE-197 INT02-C Understand integer conversion rules
  • CWE-197 INT05-C Do not use input functions to convert character data if they cannot handle all possible inputs
  • CWE-197 INT31-C Ensure that integer conversions do not result in lost or misinterpreted data
  • CWE-369 INT33-C Ensure that division and modulo operations do not result in divide-by-zero errors
  • CWE-466 INT11-C Take care when converting from pointer to integer or integer to pointer
  • CWE-587 INT11-C Take care when converting from pointer to integer or integer to pointer
  • CWE-606 INT03-C Use a secure integer library
  • CWE-676 INT06-C Use strtol() or a related function to convert a string token to an integer
  • CWE-681 INT15-C Use intmax_t or uintmax_t for formatted IO on programmer-defined integer types
  • CWE-681 INT31-C Ensure that integer conversions do not result in lost or misinterpreted data
  • CWE-681 INT35-C Evaluate integer expressions in a larger size before comparing or assigning to that size
  • CWE-682 INT07-C Use only explicitly signed or unsigned char type for numeric values
  • CWE-682 INT13-C Use bitwise operators only on unsigned operands
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 04 - Integers (INT)
2019-01-03CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)

Category ID: 739
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberBaseBase - 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.369Divide By Zero
HasMemberBaseBase - 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.681Incorrect Conversion between Numeric Types
HasMemberPillarPillar - 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.682Incorrect Calculation
HasMemberVariantVariant - 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.686Function Call With Incorrect Argument Type
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-369 FLP03-C Detect and handle floating point errors
  • CWE-681 FLP33-C Convert integers to floating point for floating point operations
  • CWE-681 FLP34-C Ensure that floating point conversions are within range of the new type
  • CWE-682 FLP32-C Prevent or detect domain and range errors in math functions
  • CWE-682 FLP33-C Convert integers to floating point for floating point operations
  • CWE-686 FLP31-C Do not call functions expecting real values with complex values
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, References, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 05 - Floating Point (FLP)
2019-01-03CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)

Category ID: 740
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberVariantVariant - 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.129Improper Validation of Array Index
HasMemberVariantVariant - 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.467Use of sizeof() on a Pointer Type
HasMemberBaseBase - 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.469Use of Pointer Subtraction to Determine Size
HasMemberClassClass - 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.665Improper Initialization
HasMemberBaseBase - 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.805Buffer Access with Incorrect Length Value
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-119 ARR00-C Understand how arrays work
  • CWE-119 ARR33-C Guarantee that copies are made into storage of sufficient size
  • CWE-119 ARR34-C Ensure that array types in expressions are compatible
  • CWE-119 ARR35-C Do not allow loops to iterate beyond the end of an array
  • CWE-129 ARR00-C Understand how arrays work
  • CWE-129 ARR30-C Guarantee that array indices are within the valid range
  • CWE-129 ARR38-C Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element
  • CWE-467 ARR01-C Do not apply the sizeof operator to a pointer when taking the size of an array
  • CWE-469 ARR36-C Do not subtract or compare two pointers that do not refer to the same array
  • CWE-469 ARR37-C Do not add or subtract an integer to a pointer to a non-array object
  • CWE-665 ARR02-C Explicitly specify array bounds, even if implicitly defined by an initializer
  • CWE-805 ARR33-C Guarantee that copies are made into storage of sufficient size
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-09-13CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 06 - Arrays (ARR)
2019-01-03CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)

Category ID: 741
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
HasMemberBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
HasMemberClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
HasMemberBaseBase - 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.135Incorrect Calculation of Multi-Byte String Length
HasMemberBaseBase - 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.170Improper Null Termination
HasMemberBaseBase - 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.193Off-by-one Error
HasMemberBaseBase - 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.464Addition of Data Structure Sentinel
HasMemberVariantVariant - 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.686Function Call With Incorrect Argument Type
HasMemberClassClass - 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.704Incorrect Type Conversion or Cast
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-78 STR02-C Sanitize data passed to complex subsystems
  • CWE-88 STR02-C Sanitize data passed to complex subsystems
  • CWE-119 STR31-C Guarantee that storage for strings has sufficient space for character data and the null terminator
  • CWE-119 STR32-C Null-terminate byte strings as required
  • CWE-119 STR33-C Size wide character strings correctly
  • CWE-120 STR35-C Do not copy data from an unbounded source to a fixed-length array
  • CWE-135 STR33-C Size wide character strings correctly
  • CWE-170 STR03-C Do not inadvertently truncate a null-terminated byte string
  • CWE-170 STR32-C Null-terminate byte strings as required
  • CWE-193 STR31-C Guarantee that storage for strings has sufficient space for character data and the null terminator
  • CWE-464 STR03-C Do not inadvertently truncate a null-terminated byte string
  • CWE-464 STR06-C Do not assume that strtok() leaves the parse string unchanged
  • CWE-686 STR37-C Arguments to character handling functions must be representable as an unsigned char
  • CWE-704 STR34-C Cast characters to unsigned types before converting to larger integer sizes
  • CWE-704 STR37-C Arguments to character handling functions must be representable as an unsigned char
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 07 - Characters and Strings (STR)
2019-01-03CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)

CWE CATEGORY: CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)

Category ID: 742
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) chapter of the CERT C Secure Coding Standard (2008).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).734Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMemberClassClass - 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.20Improper Input Validation
HasMemberClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberBaseBase - 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.128Wrap-around Error
HasMemberBaseBase - 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.131Incorrect Calculation of Buffer Size
HasMemberBaseBase - 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.190Integer Overflow or Wraparound
HasMemberBaseBase - 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.226Sensitive Information in Resource Not Removed Before Reuse
HasMemberVariantVariant - 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.244Improper Clearing of Heap Memory Before Release ('Heap Inspection')
HasMemberBaseBase - 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.252Unchecked Return Value
HasMemberVariantVariant - 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.415Double Free
HasMemberVariantVariant - 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.416Use After Free
HasMemberBaseBase - 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.476NULL Pointer Dereference
HasMemberVariantVariant - 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.528Exposure of Core Dump File to an Unauthorized Control Sphere
HasMemberVariantVariant - 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.590Free of Memory not on the Heap
HasMemberVariantVariant - 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.591Sensitive Data Storage in Improperly Locked Memory
HasMemberBaseBase - 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.628Function Call with Incorrectly Specified Arguments
HasMemberClassClass - 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.665Improper Initialization
HasMemberVariantVariant - 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.687Function Call With Incorrectly Specified Argument Value
HasMemberClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Notes

Relationship

In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:

  • CWE-20 MEM10-C Define and use a pointer validation function
  • CWE-119 MEM09-C Do not assume memory allocation routines initialize memory
  • CWE-128 MEM07-C Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t
  • CWE-131 MEM35-C Allocate sufficient memory for an object
  • CWE-190 MEM07-C Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t
  • CWE-190 MEM35-C Allocate sufficient memory for an object
  • CWE-226 MEM03-C Clear sensitive information stored in reusable resources returned for reuse
  • CWE-244 MEM03-C Clear sensitive information stored in reusable resources returned for reuse
  • CWE-252 MEM32-C Detect and handle memory allocation errors
  • CWE-415 MEM00-C Allocate and free memory in the same module, at the same level of abstraction
  • CWE-415 MEM01-C Store a new value in pointers immediately after free()
  • CWE-415 MEM31-C Free dynamically allocated memory exactly once
  • CWE-416 MEM00-C Allocate and free memory in the same module, at the same level of abstraction
  • CWE-416 MEM01-C Store a new value in pointers immediately after free()
  • CWE-416 MEM30-C Do not access freed memory
  • CWE-476 MEM32-C Detect and handle memory allocation errors
  • CWE-528 MEM06-C Ensure that sensitive data is not written out to disk
  • CWE-590 MEM34-C Only free memory allocated dynamically
  • CWE-591 MEM06-C Ensure that sensitive data is not written out to disk
  • CWE-628 MEM08-C Use realloc() only to resize dynamically allocated arrays
  • CWE-665 MEM09-C Do not assume memory allocation routines initialize memory
  • CWE-687 MEM04-C Do not perform zero length allocations
  • CWE-754 MEM32-C Detect and handle memory allocation errors
+ References
[REF-597] Robert C. Seacord. "The CERT C Secure Coding Standard". 1st Edition. Addison-Wesley Professional. 2008-10-14.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-09-13CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2019-01-03CWE Content TeamMITRE
updated Description, Name, References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 08 - Memory Management (MEM)
2019-01-03CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)

CWE-482: Comparing instead of Assigning

Weakness ID: 482
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: VariantVariant - 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.
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


+ Description
The code uses an operator for comparison when the intention was to perform an assignment.
+ Extended Description
In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Availability
Integrity

Technical Impact: Unexpected State

The assignment will not take place, which should cause obvious program execution problems.
+ Potential Mitigations

Phase: Testing

Many IDEs and static analysis products will detect this problem.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.480Use of Incorrect Operator
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
ImplementationThis bug primarily originates from a typo.
+ Applicable Platforms
Section HelpThis 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)

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
void called(int foo) {
foo==1;
if (foo==1) System.out.println("foo\n");
}
int main() {

called(2);
return 0;
}

Example 2

The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable.

(bad code)
Example Language:
#define SIZE 50
int *tos, *p1, stack[SIZE];

void push(int i) {
p1++;
if(p1==(tos+SIZE)) {

// Print stack overflow error message and exit
}
*p1 == i;
}

int pop(void) {
if(p1==tos) {

// Print stack underflow error message and exit
}
p1--;
return *(p1+1);
}

int main(int argc, char *argv[]) {

// initialize tos and p1 to point to the top of stack
tos = stack;
p1 = stack;
// code to add and remove items from stack
...
return 0;
}

The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable.

However, this expression uses the comparison operator "==" rather than the assignment operator "=". The result of using the comparison operator instead of the assignment operator causes erroneous values to be entered into the stack and can cause unexpected results.


+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPComparing instead of assigning
Software Fault PatternsSFP2Unused Entities
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Modes_of_Introduction
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-14: Compiler Removal of Code to Clear Buffers

Weakness ID: 14
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: VariantVariant - 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.
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


+ Description
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."
+ Extended Description

This compiler optimization error occurs when:

  1. Secret data are stored in memory.
  2. The secret data are scrubbed from memory by overwriting its contents.
  3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Memory; Bypass Protection Mechanism

This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.
+ Potential Mitigations

Phase: Implementation

Store the sensitive data in a "volatile" memory location if available.

Phase: Build and Compilation

If possible, configure your compiler so that it does not remove dead stores.

Phase: Architecture and Design

Where possible, encrypt sensitive data that are used by a software system.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.733Compiler Optimization Removal or Modification of Security-critical Code
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
Build and Compilation
+ Applicable Platforms
Section HelpThis 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)

+ Demonstrative Examples

Example 1

The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset().

(bad code)
Example Language:
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {

if (ConnectToMainframe(MFAddr, pwd)) {

// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}

The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system.

It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency.

Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.


+ Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.
+ Affected Resources
  • Memory
+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInsecure Compiler Optimization
PLOVERSensitive memory uncleared by compiler optimization
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMSC06-CBe aware of compiler optimization when dealing with sensitive data
Software Fault PatternsSFP23Exposed Data
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-124] Michael Howard. "When scrubbing secrets in memory doesn't work". BugTraq. 2002-11-05. <http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html>.
[REF-125] Michael Howard. "Some Bad News and Some Good News". Microsoft. 2002-10-21. <https://learn.microsoft.com/en-us/previous-versions/ms972826(v=msdn.10)>. URL validated: 2023-04-07.
[REF-126] Joseph Wagner. "GNU GCC: Optimizer Removes Code Necessary for Security". Bugtraq. 2002-11-16. <https://seclists.org/bugtraq/2002/Nov/266>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes, Potential_Mitigations, Relationships, Taxonomy_Mappings, Time_of_Introduction
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References, Type
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Description
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insecure Compiler Optimization

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Weakness ID: 362
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: ClassClass - 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.
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


+ Description
The product contains a code sequence that can run concurrently with other code, and the code sequence 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 that is operating concurrently.
+ Extended Description

This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

A race condition occurs within concurrent environments, and is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc.

A race condition violates these properties, which are closely related:

  • Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.
  • Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion (CWE-400).
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Confidentiality
Integrity

Technical Impact: Read Files or Directories; Read Application Data

When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
+ Potential Mitigations

Phase: Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Phase: Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.

Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Phase: Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Phase: Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Phase: Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Phase: Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Phase: Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - 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.364Signal Handler Race Condition
ParentOfBaseBase - 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.366Race Condition within a Thread
ParentOfBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOfBaseBase - 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.368Context Switching Race Condition
ParentOfBaseBase - 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.421Race Condition During Access to Alternate Channel
ParentOfCompositeComposite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.689Permission Race Condition During Resource Copy
ParentOfBaseBase - 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.1223Race Condition for Write-Once Attributes
ParentOfBaseBase - 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.1298Hardware Logic Contains Race Conditions
CanFollowClassClass - 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.662Improper Synchronization
CanPrecedeVariantVariant - 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.416Use After Free
CanPrecedeBaseBase - 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.476NULL Pointer Dereference
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOfBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis 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 (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account.

(bad code)
Example Language: Perl 
$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Suppose the balance is initially 100.00. An attack could be constructed as follows:

(attack code)
Example Language: Other 
In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00

At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database.

To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase().


Example 2

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 3

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.


+ Observed Examples
ReferenceDescription
Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and deleted.
TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
+ Detection Methods

Black Box

Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.

White Box

Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Race conditions may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior.

Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect.

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Cost effective for partial coverage:
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Framework-based Fuzzer
Cost effective for partial coverage:
  • Fuzz Tester
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1376ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ Notes

Research Gap

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Research Gap

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
The CERT Oracle Secure Coding Standard for Java (2011)VNA03-JDo not assume that a group of calls to independently atomic methods is atomic
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. URL validated: 2023-04-07.
[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. URL validated: 2023-04-07.
[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. URL validated: 2023-04-07.
[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. URL validated: 2023-04-07.
[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. URL validated: 2023-04-07.
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. URL validated: 2023-04-07.
[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. URL validated: 2023-04-07.
[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Observed_Examples, References
2022-04-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

CWE-379: Creation of Temporary File in Directory with Insecure Permissions

Weakness ID: 379
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - 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.
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


+ Description
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.
+ Extended Description
On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Since the file is visible and the application which is using the temp file could be known, the attacker has gained information about what the user is doing at that time.
+ Potential Mitigations

Phase: Requirements

Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.

Phase: Implementation

Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories.

Phase: Implementation

Avoid using vulnerable temp file functions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.377Insecure Temporary File
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis 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 (Undetermined Prevalence)

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

In the following code examples a temporary file is created and written to. After using the temporary file, the file is closed and deleted from the file system.

(bad code)
Example Language:
FILE *stream;
if( (stream = tmpfile()) == NULL ) {

perror("Could not open new temporary file\n");
return (-1);
}
// write data to tmp file
...
// remove tmp file
rmtmp();

However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file.

(bad code)
Example Language: Java 
try {
File temp = File.createTempFile("pattern", ".suffix");
temp.deleteOnExit();
BufferedWriter out = new BufferedWriter(new FileWriter(temp));
out.write("aString");
out.close();
}
catch (IOException e) {
}

Similarly, the createTempFile() method used in the Java code creates a temp file that may be readable and writable to all users.

Additionally both methods used above place the file into a default directory. On UNIX systems the default directory is usually "/tmp" or "/var/tmp" and on Windows systems the default directory is usually "C:\\Windows\\Temp", which may be easily accessible to attackers, possibly enabling them to read and modify the contents of the temp file.


+ Observed Examples
ReferenceDescription
A hotkey daemon written in Rust creates a domain socket file underneath /tmp, which is accessible by any user.
A Java-based application for a rapid-development framework uses File.createTempFile() to create a random temporary file with insecure default permissions.
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.964SFP Secondary Cluster: Exposure Temporary File
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPGuessed or visible temporary file
CERT C Secure CodingFIO15-CEnsure that file operations are performed in a secure directory
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Temporary Files", Page 538. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Name, References, Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Guessed or Visible Temporary File
2009-05-27Creation of Temporary File in Directory with Insecure Permissions
2020-02-24Creation of Temporary File in Directory with Incorrect Permissions

CWE-561: Dead Code

Weakness ID: 561
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - 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.
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


+ Description
The product contains dead code, which can never be executed.
+ Extended Description
Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.
+ Common Consequences
Section HelpThis 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.
Other

Technical Impact: Reduce Maintainability

+ Potential Mitigations

Phase: Implementation

Remove dead code before deploying the application.

Phase: Testing

Use a static analysis tool to spot dead code.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1164Irrelevant Code
CanFollowBaseBase - 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.570Expression is Always False
CanFollowBaseBase - 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.571Expression is Always True
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ Modes Of Introduction
Section HelpThe 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.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis 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 (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement.

(bad code)
Example Language: C++ 
String s = null;
if (b) {
s = "Yes";
return;
}

if (s != null) {
Dead();
}

Example 2

In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code.

(bad code)
Example Language: Java 
public class DoubleDead {
private void doTweedledee() {
doTweedledumb();
}
private void doTweedledumb() {
doTweedledee();
}
public static void main(String[] args) {
System.out.println("running DoubleDead");
}
}

(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)


Example 3

The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant.

(bad code)
Example Language: Java 
public class Dead {
String glue;

public String getGlue() {
return "glue";
}
}

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Attack Modeling

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Binary / Bytecode Quality Analysis
  • Compare binary / bytecode to application permission manifest

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Automated Monitored Execution

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source Code Quality Analyzer
Cost effective for partial coverage:
  • Warning Flags
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

+ Memberships
Section HelpThis 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures (2016) - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1186SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC07-CDetect and remove dead code
SEI CERT Perl Coding StandardMSC00-PLExactDetect and remove dead code
Software Fault PatternsSFP2Unused Entities
OMG ASCMMASCMM-MNT-20
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-20. 2016-01. <https://www.omg.org/spec/ASCMM/>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Observed_Examples