Home > CWE List > VIEW SLICE: CWE-734: Weaknesses Addressed by the CERT C Secure Coding Standard (2008) (4.15) |
|
CWE VIEW: Weaknesses Addressed by the CERT C Secure Coding Standard (2008)
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.
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 - 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Use of sizeof() on a Pointer Type - (467) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 467 (Use of sizeof() on a Pointer Type) The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.NULL Pointer Dereference - (476) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 737 (CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)) > 476 (NULL Pointer Dereference) The product dereferences a pointer that it expects to be valid but is NULL.NPDnull derefNPEnil pointer dereference 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Improper Validation of Array Index - (129) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 738 (CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)) > 129 (Improper Validation of Array Index) The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow 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.OverflowWraparoundwrap, wrap-around, wrap around Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Integer Coercion Error - (192) 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety 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 indexindex-out-of-rangearray index underflow Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Use of sizeof() on a Pointer Type - (467) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 740 (CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)) > 467 (Use of sizeof() on a Pointer Type) The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated. 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety 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 OverflowUnbounded Transfer Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 741 (CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')) The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharactersOS Command Injection 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 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Integer Overflow or Wraparound - (190) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)) > 190 (Integer Overflow or Wraparound) The product performs a calculation that can
produce an integer overflow or wraparound when the logic
assumes that the resulting value will always be larger than
the original value. This occurs when an integer value is
incremented to a value that is too large to store in the
associated representation. When this occurs, the value may
become a very small or negative number.OverflowWraparoundwrap, wrap-around, wrap around 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Use After Free - (416) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 742 (CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)) > 416 (Use After Free) The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.Dangling pointerUAFUse-After-Free 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.NPDnull derefNPEnil pointer dereference Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Exposure of Core Dump File to an Unauthorized Control Sphere - (528) 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - 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 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')) The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. 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.TOCTTOUTOCCTOU 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Link Resolution Before File Access ('Link Following') - (59) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 59 (Improper Link Resolution Before File Access ('Link Following')) The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary fileZip Slip 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Windows Shortcut Following (.LNK) - (64) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 743 (CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)) > 64 (Windows Shortcut Following (.LNK)) The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.Windows symbolic link followingsymlink 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 744 (CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')) The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharactersOS Command Injection 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 - 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 - 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 - 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - 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 - 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Link Resolution Before File Access ('Link Following') - (59) 734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008)) > 748 (CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)) > 59 (Improper Link Resolution Before File Access ('Link Following')) The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary fileZip Slip 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 - 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 - 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.
Relationship The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-464: Addition of Data Structure Sentinel
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe accidental addition of a data-structure sentinel can cause serious programming logic problems. Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 The following example assigns some character values to a list of characters and prints them each individually, and then as a string. The third character value is intended to be an integer taken from user input and converted to an int. (bad code) Example Language: C char *foo;
foo=malloc(sizeof(char)*5); foo[0]='a'; foo[1]='a'; foo[2]=atoi(getc(stdin)); foo[3]='c'; foo[4]='\0' printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3],foo[4]); printf("%s\n",foo); The first print statement will print each character separated by a space. However, if a non-integer is read from stdin by getc, then atoi will not make a conversion and return 0. When foo is printed as a string, the 0 at character foo[2] will act as a NULL terminator and foo[3] will never be printed. This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-587: Assignment of a Fixed Address to a Pointer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterUsing a fixed address is not portable, because that address will probably not be valid in all environments or platforms. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) C# (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) Example 1 This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function. (bad code) Example Language: C int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b'); // Here we can inject code to execute. The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-563: Assignment to Variable without Use
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterAfter the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Example 1 The following code excerpt assigns to the variable r and then overwrites the value without using it. (bad code) Example Language: C r = getName();
r = getNewBuffer(buf);
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-805: Buffer Access with Incorrect Length Value
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer. When the length value exceeds the size of the destination, a buffer overflow could occur. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Often Prevalent) C++ (Often Prevalent) Class: Assembly (Undetermined Prevalence) Example 1 This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer. (bad code) Example Language: C void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr; char hostname[64]; in_addr_t inet_addr(const char *cp); /*routine that ensures user_supplied_addr is in the right format for conversion */ validate_addr_form(user_supplied_addr); addr = inet_addr(user_supplied_addr); hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET); strcpy(hostname, hp->h_name); This function allocates a buffer of 64 bytes to store the hostname under the assumption that the maximum length value of hostname is 64 bytes, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker. Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476). Example 2 In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: (bad code) Example Language: C int returnChunkSize(void *) {
/* if chunk info is valid, return the size of usable memory, * else, return -1 to indicate an error */ ... int main() { ... }memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1)); ... If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788). Example 3 In the following example, the source character string is copied to the dest character string using the method strncpy. (bad code) Example Language: C ...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(source)-1); ... However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below. (good code) Example Language: C ...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(dest)-1); ... Example 4 In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file. (bad code) Example Language: C #define LOG_INPUT_SIZE 40
// saves the file name to a log file int outputFilenameToLog(char *filename, int length) { int success;
// buffer with size set to maximum size for input to log file char buf[LOG_INPUT_SIZE]; // copy filename to buffer strncpy(buf, filename, length); // save to log file success = saveToLogFile(buf); return success; However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below. (good code) Example Language: C ...
// copy filename to buffer strncpy(buf, filename, sizeof(buf)-1); ... Example 5 Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units, (one in bytes, the other in characters) making their use prone to error. In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow. The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string. (bad code) Example Language: C void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1]; }MultiByteToWideChar(CP_ACP, 0, username, -1, unicodeUser, sizeof(unicodeUser)); NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info); This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated. If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) Example 1 The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array. (bad code) Example Language: C char last_name[20];
printf ("Enter your last name: "); scanf ("%s", last_name); The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. Example 2 The following code attempts to create a local copy of a buffer to perform some manipulations to the data. (bad code) Example Language: C void manipulate_string(char * string){
char buf[24]; }strcpy(buf, string); ... However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter. Example 3 The code below calls the gets() function to read in data from the command line. (bad code) Example Language: C char buf[24]; }printf("Please enter your name and press <Enter>\n"); gets(buf); ... However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition. Example 4 In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file. (bad code) Example Language: C ...
struct hostent *clienthp;
char hostname[MAX_LEN]; // create server socket, bind to server address and listen on socket ... // accept client connections and process requests int count = 0; for (count = 0; count < MAX_CONNECTIONS; count++) { int clientlen = sizeof(struct sockaddr_in); int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen); if (clientsocket >= 0) { clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name); logOutput("Accepted client connection from host ", hostname); // process client request ... close(clientsocket); close(serversocket); ... However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them. Terminology 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.
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE CATEGORY: 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).
Relationship In the 2008 version of the CERT C Secure Coding standard, the following rules were mapped to the following CWE IDs:
CWE-482: Comparing instead of Assigning
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code uses an operator for comparison when the intention was to perform an assignment. In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 The following example demonstrates the weakness. (bad code) Example Language: Java void called(int foo) {
foo==1; }if (foo==1) System.out.println("foo\n"); int main() { called(2); return 0; Example 2 The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable. (bad code) Example Language: C #define SIZE 50
int *tos, *p1, stack[SIZE]; void push(int i) { p1++;
if(p1==(tos+SIZE)) { // Print stack overflow error message and exit *p1 == i; int pop(void) { if(p1==tos) {
// Print stack underflow error message and exit p1--; return *(p1+1); int main(int argc, char *argv[]) { // initialize tos and p1 to point to the top of stack tos = stack; p1 = stack; // code to add and remove items from stack ... return 0; The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable. However, this expression uses the comparison operator "==" rather than the assignment operator "=". The result of using the comparison operator instead of the assignment operator causes erroneous values to be entered into the stack and can cause unexpected results.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-14: Compiler Removal of Code to Clear Buffers
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 FilterSensitive 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." This compiler optimization error occurs when:
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset(). (bad code) Example Language: C void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) { if (ConnectToMainframe(MFAddr, pwd)) { // Interaction with mainframe memset(pwd, 0, sizeof(pwd)); The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system. It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency. Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider. A race condition occurs within concurrent environments, and is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related:
A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x). The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Sometimes Prevalent) C++ (Sometimes Prevalent) Java (Sometimes Prevalent) Technologies Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Example 1 This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account. (bad code) Example Language: Perl $transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase(); if ($transfer_amount < 0) { FatalError("Bad Transfer Amount"); }$newbalance = $balance - $transfer_amount; if (($balance - $transfer_amount) < 0) { FatalError("Insufficient Funds"); }SendNewBalanceToDatabase($newbalance); NotifyUser("Transfer of $transfer_amount succeeded."); NotifyUser("New balance: $newbalance"); A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase(). Suppose the balance is initially 100.00. An attack could be constructed as follows: (attack code) Example Language: Other In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2. CALLER-1 makes a transfer request of 80.00. PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00 PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase(). Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay. CALLER-2 makes a transfer request of 1.00. PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet. PROGRAM-2 determines the new balance as 99.00. After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00. PROGRAM-2 sends a request to update the database, setting the balance to 99.00 At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database. To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase(). Example 2 The following function attempts to acquire a lock in order to perform operations on a shared resource. (bad code) Example Language: C void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */ pthread_mutex_unlock(mutex); However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior. In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels. (good code) Example Language: C int f(pthread_mutex_t *mutex) {
int result;
result = pthread_mutex_lock(mutex); if (0 != result) return result;
/* access shared resource */ return pthread_mutex_unlock(mutex); Example 3 Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs. Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Research Gap Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area. Research Gap Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check. Research Gap From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues. Maintenance The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
CWE-379: Creation of Temporary File in Directory with Insecure Permissions
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file. On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 In the following code examples a temporary file is created and written to. After using the temporary file, the file is closed and deleted from the file system. (bad code) Example Language: C FILE *stream;
if( (stream = tmpfile()) == NULL ) { perror("Could not open new temporary file\n"); return (-1); // write data to tmp file ... // remove tmp file rmtmp(); However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file. (bad code) Example Language: Java try {
File temp = File.createTempFile("pattern", ".suffix"); }temp.deleteOnExit(); BufferedWriter out = new BufferedWriter(new FileWriter(temp)); out.write("aString"); out.close(); catch (IOException e) { } Similarly, the createTempFile() method used in the Java code creates a temp file that may be readable and writable to all users. Additionally both methods used above place the file into a default directory. On UNIX systems the default directory is usually "/tmp" or "/var/tmp" and on Windows systems the default directory is usually "C:\\Windows\\Temp", which may be easily accessible to attackers, possibly enabling them to read and modify the contents of the temp file.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-561: Dead Code
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 FilterDead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement. (bad code) Example Language: C++ String s = null;
if (b) { s = "Yes"; }return; if (s != null) { Dead(); }Example 2 In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code. (bad code) Example Language: Java public class DoubleDead {
private void doTweedledee() { }doTweedledumb(); }private void doTweedledumb() { doTweedledee(); }public static void main(String[] args) { System.out.println("running DoubleDead"); }(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.) Example 3 The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant. (bad code) Example Language: Java public class Dead {
String glue;
public String getGlue() { return "glue"; }
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
|