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.16)  
ID

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

View ID: 734
Vulnerability Mapping: PROHIBITED This 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
Stakeholder Description
Software Developers By 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 Customers If 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.
Educators Educators 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)
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect 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.
+ Category Category - 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).
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Function Call With Incorrect Argument Type - (686)
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.
+ Category Category - 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).
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of sizeof() on a Pointer Type - (467)
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 pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. NULL Pointer Dereference - (476)
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. NPD null deref NPE nil pointer dereference
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Type Conversion or Cast - (704)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
+ Category Category - 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).
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Validation of Array Index - (129)
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 index index-out-of-range array index underflow
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Integer Overflow or Wraparound - (190)
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. Overflow Wraparound wrap, wrap-around, wrap around
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Integer Coercion Error - (192)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Numeric Truncation Error - (197)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Input Validation - (20)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Divide By Zero - (369)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Return of Pointer Value Outside of Expected Range - (466)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Assignment of a Fixed Address to a Pointer - (587)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unchecked Input for Loop Condition - (606)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Potentially Dangerous Function - (676)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Conversion between Numeric Types - (681)
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.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Incorrect Calculation - (682)
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.
+ Category Category - 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).
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Divide By Zero - (369)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Conversion between Numeric Types - (681)
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.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Incorrect Calculation - (682)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Function Call With Incorrect Argument Type - (686)
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.
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
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 Overflow buffer overrun memory safety
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Validation of Array Index - (129)
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 index index-out-of-range array index underflow
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of sizeof() on a Pointer Type - (467)
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 pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Pointer Subtraction to Determine Size - (469)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Initialization - (665)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Buffer Access with Incorrect Length Value - (805)
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.
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
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 Overflow buffer overrun memory safety
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
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 Overflow Unbounded Transfer
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Calculation of 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Null Termination - (170)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Off-by-one Error - (193)
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
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Addition of Data Structure Sentinel - (464)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Function Call With Incorrect Argument Type - (686)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Type Conversion or Cast - (704)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
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 injection Shell metacharacters OS Command Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)
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.
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
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 Overflow buffer overrun memory safety
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Wrap-around Error - (128)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Calculation of Buffer Size - (131)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Integer Overflow or Wraparound - (190)
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. Overflow Wraparound wrap, wrap-around, wrap around
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Input Validation - (20)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Sensitive Information in Resource Not Removed Before Reuse - (226)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Clearing of Heap Memory Before Release ('Heap Inspection') - (244)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unchecked Return Value - (252)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Double Free - (415)
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
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use After Free - (416)
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 pointer UAF Use-After-Free
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. NULL Pointer Dereference - (476)
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. NPD null deref NPE nil pointer dereference
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Core Dump File to an Unauthorized Control Sphere - (528)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Free of Memory not on the Heap - (590)
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().
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Sensitive Data Storage in Improperly Locked Memory - (591)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Initialization - (665)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Function Call With Incorrectly Specified Argument Value - (687)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Check for Unusual or Exceptional Conditions - (754)
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.
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
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 Overflow buffer overrun memory safety
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Externally-Controlled Format String - (134)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
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 traversal Path traversal
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Unexpected Data Type - (241)
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).
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Default Permissions - (276)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Execution-Assigned Permissions - (279)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
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 concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. Race Condition
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Time-of-check Time-of-use (TOCTOU) Race Condition - (367)
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. TOCTTOU TOCCTOU
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Path Traversal: '/absolute/pathname/here' - (37)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Creation of Temporary File in Directory with Insecure Permissions - (379)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Path Traversal: '\absolute\pathname\here' - (38)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Path Traversal: 'C:dirname' - (39)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unchecked Error Condition - (391)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') - (403)
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
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Resource Shutdown or Release - (404)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Resolution of Path Equivalence - (41)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Files or Directories Accessible to External Parties - (552)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Link Resolution Before File Access ('Link Following') - (59)
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 file Zip Slip
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. UNIX Hard Link - (62)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Windows Shortcut Following (.LNK) - (64)
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 following symlink
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Windows Hard Link - (65)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Windows Device Names - (67)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Multiple Operations on Resource in Single-Operation Context - (675)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Potentially Dangerous Function - (676)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Function Call With Incorrect Argument Type - (686)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Permission Assignment for Critical Resource - (732)
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.
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
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 Overflow buffer overrun memory safety
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Untrusted Search Path - (426)
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
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Duplicate Key in Associative List (Alist) - (462)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Control Flow Scoping - (705)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
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 injection Shell metacharacters OS Command Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)
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.
+ Category Category - 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).
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Signal Handler Use of a Non-reentrant Function - (479)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Synchronization - (662)
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.
+ Category Category - 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).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Input Validation - (20)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unchecked Error Condition - (391)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Standardized Error Handling Mechanism - (544)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Potentially Dangerous Function - (676)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Control Flow Scoping - (705)
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.
+ Category Category - 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).
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Compiler Removal of Code to Clear Buffers - (14)
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."
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Unicode Encoding - (176)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Input Validation - (20)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Use of Insufficiently Random Values - (330)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Incorrect Operator - (480)
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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Comparing instead of Assigning - (482)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Dead Code - (561)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Assignment to Variable without Use - (563)
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
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Expression is Always False - (570)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Expression is Always True - (571)
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.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Incorrect Comparison - (697)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Type Conversion or Cast - (704)
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.
+ Category Category - 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).
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Null Termination - (170)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Race Condition 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Race Condition within a Thread - (366)
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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Return of 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Link Resolution Before File Access ('Link Following') - (59)
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 file Zip Slip
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Function Call With Incorrect Argument Type - (686)
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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect 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 view Total CWEs
Weaknesses 91 out of 940
Categories 14 out of 374
Views 0 out of 51
Total 105 out of 1365
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2017-11-08 CWE Content Team MITRE
updated Description, Maintenance_Notes, Name, References
2019-01-03 CWE Content Team MITRE
updated Description, Name, References
2020-02-24 CWE Content Team MITRE
updated View_Audience
2021-03-15 CWE Content Team MITRE
updated Description, Maintenance_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2017-11-08 Weaknesses Addressed by the CERT C Secure Coding Standard
2019-01-03 Weaknesses 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: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
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.
Scope Impact Likelihood
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 Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 138 Improper Neutralization of Special Elements
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 170 Improper Null Termination
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 463 Deletion of Data Structure Sentinel
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data 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.
Phase Note
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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 741 CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 875 CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1407 Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may 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 Name Node ID Fit Mapped Node Name
CLASP Addition of data-structure sentinel
CERT C Secure Coding STR03-C Do not inadvertently truncate a null-terminated byte string
CERT C Secure Coding STR06-C Do 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>. URL validated: 2024-11-17.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Addition of Data-structure Sentinel

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

Weakness ID: 587
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
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.
Scope Impact Likelihood
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 Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 344 Use of Invariant Value in Dynamically Changing Context
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 758 Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 465 Pointer 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.
Phase Note
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
Ordinality Description
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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 738 CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 872 CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 998 SFP Secondary Cluster: Glitch in Computation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1158 SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may 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 Name Node ID Fit Mapped Node Name
CERT C Secure Coding INT36-C Imprecise Converting a pointer to integer or integer to pointer
Software Fault Patterns SFP1 Glitch in computation
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-01 KDM Analytics
added/updated white box definitions
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-03-10 CWE Content Team MITRE
updated Relationships
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Description, Other_Notes
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions
2019-01-03 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Common_Consequences, Weakness_Ordinalities
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction, Type
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples

CWE-563: Assignment to Variable without Use

Weakness ID: 563
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
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.
Scope Impact Likelihood
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 Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1164 Irrelevant Code
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1006 Bad 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.
Phase Note
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
Ordinality Description
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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 747 CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 883 CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 886 SFP Primary Cluster: Unused entities
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1186 SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may 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 Name Node ID Fit Mapped Node Name
CERT C Secure Coding MSC00-C Compile cleanly at high warning levels
SEI CERT Perl Coding Standard MSC01-PL Imprecise Detect and remove unused variables
Software Fault Patterns SFP2 Unused Entities
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-06-23 CWE Content Team MITRE
updated Common_Consequences, Description, Name, Other_Notes
2014-07-30 CWE Content Team MITRE
updated Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Alternate_Terms, Name, Relationships, Taxonomy_Mappings
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships, Type
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2014-06-23 Unused Variable
2017-11-08 Assignment to Variable without Use ('Unused Variable')

CWE-805: Buffer Access with Incorrect Length Value

Weakness ID: 805
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
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.
Scope Impact Likelihood
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 Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 806 Buffer Access Using Size of Source Buffer
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 130 Improper Handling of Length Parameter Inconsistency
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1218 Memory Buffer Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper 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.
Phase Note
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
Reference Description
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
Ordinality Description
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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 740 CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 874 CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1160 SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may 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 Name Node ID Fit Mapped Node Name
CERT C Secure Coding ARR38-C Imprecise Guarantee 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 Date Submitter Organization
2010-01-15
(CWE 1.8, 2010-02-16)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-02-18 CWE Content Team MITRE
updated Potential_Mitigations, References
2014-06-23 CWE Content Team MITRE
updated Demonstrative_Examples
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References
2019-01-03 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Common_Consequences
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2022-10-13 CWE Content Team MITRE
updated References
2023-01-31 CWE Content Team MITRE
updated Description, Detection_Factors, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples

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

Weakness ID: 120
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
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.
Scope Impact Likelihood
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 Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 785 Use of Path Manipulation Function without Maximum-sized Buffer
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 170 Improper Null Termination
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 231 Improper Handling of Extra Values
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 416 Use After Free
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 456 Missing Initialization of a Variable
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 123 Write-what-where Condition
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1218 Memory Buffer Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 20 Improper 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.
Phase Note
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
Reference Description
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
Ordinality Description
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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 726 OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 741 CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 865 2011 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 875 CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 970 SFP Secondary Cluster: Faulty Buffer Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1129 CISQ Quality Measures (2016) - Reliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1161 SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive 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 Name Node ID Fit Mapped Node Name
PLOVER Unbounded Transfer ('classic overflow')
7 Pernicious Kingdoms Buffer Overflow
CLASP Buffer overflow
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
OWASP Top Ten 2004 A5 CWE More Specific Buffer Overflows
CERT C Secure Coding STR31-C Exact Guarantee that storage for strings has sufficient space for character data and the null terminator
WASC 7 Buffer Overflow
Software Fault Patterns SFP8 Faulty Buffer Access
OMG ASCSM ASCSM-CWE-120
OMG ASCRM ASCRM-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 Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-01 KDM Analytics
added/updated white box definitions
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10 CWE Content Team MITRE
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14 CWE Content Team MITRE
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24 CWE Content Team MITRE
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29 CWE Content Team MITRE
updated Common_Consequences, Relationships
2010-02-16 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-02-18 CWE Content Team MITRE
updated Potential_Mitigations, References
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27 CWE Content Team MITRE
updated References
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Alternate_Terms, Relationships
2020-12-10 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2021-07-20 CWE Content Team MITRE
updated Potential_Mitigations
2022-10-13 CWE Content Team MITRE
updated References
2023-01-31 CWE Content Team MITRE
updated Common_Consequences, Description
2023-04-27 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2008-10-14 Unbounded Transfer ('Classic Buffer Overflow')

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

Category ID: 748
Vulnerability Mapping: PROHIBITED This 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
Nature Type ID Name
MemberOf ViewView - 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). 734 Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
HasMember 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. 59 Improper Link Resolution Before File Access ('Link Following')
HasMember 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. 170 Improper Null Termination
HasMember 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. 242 Use of Inherently Dangerous Function
HasMember 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. 272 Least Privilege Violation
HasMember 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. 273 Improper Check for Dropped Privileges
HasMember 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. 363 Race Condition Enabling Link Following
HasMember 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. 366 Race Condition within a Thread
HasMember 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. 562 Return of Stack Variable Address
HasMember 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. 667 Improper Locking
HasMember 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. 686 Function Call With Incorrect Argument Type
HasMember 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. 696 Incorrect 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 Date Submitter Organization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2017-11-08 CWE Content Team MITRE
updated Description, Name, Relationship_Notes
2019-01-03 CWE Content Team MITRE
updated Description, Name, References, Relationship_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2017-11-08 CERT C Secure Coding Section 50 - POSIX (POS)
2019-01-03 CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)

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