CWE - VIEW SLICE: CWE-868: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version) (4.10)

CWE VIEW: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)

View ID: 868

Type: Graph

Downloads: Booklet | CSV | XML

Objective

CWE entries in this view (graph) are fully or partially eliminated by following the SEI CERT C++ Coding Standard, as published in 2016. This view is no longer being actively maintained, since it statically represents the coding rules as they were in 2016.

Audience

Stakeholder	Description
Software Developers	By following the CERT C++ Secure Coding Standard, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Product Customers	If a software developer claims to be following the CERT C++ Secure Coding Standard, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
Educators	Educators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.

Relationships

The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.

Show Details:

Expand All | Collapse All

868 - Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 01 - Preprocessor (PRE) - (869)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 869 (CERT C++ Secure Coding Section 01 - Preprocessor (PRE))

Weaknesses in this category are related to rules in the Preprocessor (PRE) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL) - (870)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 870 (CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL))

Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 03 - Expressions (EXP) - (871)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP))

Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.NULL Pointer Dereference - (476)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP)) > 476 (NULL Pointer Dereference)

A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.NPDnull derefnil pointer dereference

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP)) > 480 (Use of Incorrect Operator)

The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Short Circuit Evaluation - (768)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP)) > 768 (Incorrect Short Circuit Evaluation)

The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 04 - Integers (INT) - (872)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT))

Weaknesses in this category are related to rules in the Integers (INT) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 129 (Improper Validation of Array Index)

The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 190 (Integer Overflow or Wraparound)

The product performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 192 (Integer Coercion Error)

Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 197 (Numeric Truncation Error)

Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Input Validation - (20)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 20 (Improper Input Validation)

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 369 (Divide By Zero)

The product divides a value by zero.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 466 (Return of Pointer Value Outside of Expected Range)

A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 587 (Assignment of a Fixed Address to a Pointer)

The product sets a pointer to a specific address other than NULL or 0.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 606 (Unchecked Input for Loop Condition)

The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 676 (Use of Potentially Dangerous Function)

The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 681 (Incorrect Conversion between Numeric Types)

When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.

Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.Incorrect Calculation - (682)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 682 (Incorrect Calculation)

The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP) - (873)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP))

Weaknesses in this category are related to rules in the Floating Point Arithmetic (FLP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 369 (Divide By Zero)

The product divides a value by zero.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 681 (Incorrect Conversion between Numeric Types)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 682 (Incorrect Calculation)

The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 686 (Function Call With Incorrect Argument Type)

The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR) - (874)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR))

Weaknesses in this category are related to rules in the Arrays and the STL (ARR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.Buffer Overflowbuffer overrunmemory safety

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 129 (Improper Validation of Array Index)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 467 (Use of sizeof() on a Pointer Type)

The code calls sizeof() on a 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 469 (Use of Pointer Subtraction to Determine Size)

The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 665 (Improper Initialization)

The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 805 (Buffer Access with Incorrect Length Value)

The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 07 - Characters and Strings (STR) - (875)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR))

Weaknesses in this category are related to rules in the Characters and Strings (STR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))

The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.Classic Buffer OverflowUnbounded Transfer

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 170 (Improper Null Termination)

The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 193 (Off-by-one Error)

A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.off-by-five

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 464 (Addition of Data Structure Sentinel)

The accidental addition of a data-structure sentinel can cause serious programming logic problems.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 686 (Function Call With Incorrect Argument Type)

The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 704 (Incorrect Type Conversion or Cast)

The product does not correctly convert an object, resource, or structure from one type to a different type.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))

The product constructs a string for a command to executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 08 - Memory Management (MEM) - (876)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM))

Weaknesses in this category are related to rules in the Memory Management (MEM) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 128 (Wrap-around Error)

Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 131 (Incorrect Calculation of Buffer Size)

The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 190 (Integer Overflow or Wraparound)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 20 (Improper Input Validation)

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 226 (Sensitive Information in Resource Not Removed Before Reuse)

The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 244 (Improper Clearing of Heap Memory Before Release ('Heap Inspection'))

Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 252 (Unchecked Return Value)

The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 391 (Unchecked Error Condition)

[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 404 (Improper Resource Shutdown or Release)

The product does not release or incorrectly releases a resource before it is made available for re-use.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 415 (Double Free)

The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 416 (Use After Free)

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Dangling pointerUse-After-Free

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 476 (NULL Pointer Dereference)

A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.NPDnull derefnil pointer dereference

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere)

The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 590 (Free of Memory not on the Heap)

The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 591 (Sensitive Data Storage in Improperly Locked Memory)

The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 665 (Improper Initialization)

The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 687 (Function Call With Incorrectly Specified Argument Value)

The product calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.

Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.Unchecked Return Value to NULL Pointer Dereference - (690)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 690 (Unchecked Return Value to NULL Pointer Dereference)

The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 703 (Improper Check or Handling of Exceptional Conditions)

The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 754 (Improper Check for Unusual or Exceptional Conditions)

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 762 (Mismatched Memory Management Routines)

The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 770 (Allocation of Resources Without Limits or Throttling)

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 822 (Untrusted Pointer Dereference)

The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 09 - Input Output (FIO) - (877)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO))

Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 134 (Use of Externally-Controlled Format String)

The product uses a function that accepts a format string as an argument, but the format string originates from an external source.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 241 (Improper Handling of Unexpected Data Type)

The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 276 (Incorrect Default Permissions)

During installation, installed file permissions are set to allow anyone to modify those files.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 279 (Incorrect Execution-Assigned Permissions)

While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

The product contains a 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 367 (Time-of-check Time-of-use (TOCTOU) Race Condition)

The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state.TOCTTOUTOCCTOU

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 37 (Path Traversal: '/absolute/pathname/here')

The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 379 (Creation of Temporary File in Directory with Insecure Permissions)

The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 38 (Path Traversal: '\absolute\pathname\here')

The product accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 39 (Path Traversal: 'C:dirname')

The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 391 (Unchecked Error Condition)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))

A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.File descriptor leak

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 404 (Improper Resource Shutdown or Release)

The product does not release or incorrectly releases a resource before it is made available for re-use.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 41 (Improper Resolution of Path Equivalence)

The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 552 (Files or Directories Accessible to External Parties)

The product makes files or directories accessible to unauthorized actors, even though they should not be.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 59 (Improper Link Resolution Before File Access ('Link Following'))

The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary fileZip Slip

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 62 (UNIX Hard Link)

The product, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 64 (Windows Shortcut Following (.LNK))

The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.Windows symbolic link followingsymlink

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 65 (Windows Hard Link)

The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 67 (Improper Handling of Windows Device Names)

The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 675 (Multiple Operations on Resource in Single-Operation Context)

The product performs the same operation on a resource two or more times, when the operation should only be applied once.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 676 (Use of Potentially Dangerous Function)

The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 73 (External Control of File Name or Path)

The product allows user input to control or influence paths or file names that are used in filesystem operations.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 732 (Incorrect Permission Assignment for Critical Resource)

The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 770 (Allocation of Resources Without Limits or Throttling)

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 10 - Environment (ENV) - (878)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV))

Weaknesses in this category are related to rules in the Environment (ENV) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 426 (Untrusted Search Path)

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.Untrusted Path

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 462 (Duplicate Key in Associative List (Alist))

Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 705 (Incorrect Control Flow Scoping)

The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 807 (Reliance on Untrusted Inputs in a Security Decision)

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 11 - Signals (SIG) - (879)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 879 (CERT C++ Secure Coding Section 11 - Signals (SIG))

Weaknesses in this category are related to rules in the Signals (SIG) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 879 (CERT C++ Secure Coding Section 11 - Signals (SIG)) > 479 (Signal Handler Use of a Non-reentrant Function)

The product defines a signal handler that calls a non-reentrant function.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 879 (CERT C++ Secure Coding Section 11 - Signals (SIG)) > 662 (Improper Synchronization)

The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR) - (880)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR))

Weaknesses in this category are related to rules in the Exceptions and Error Handling (ERR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 209 (Generation of Error Message Containing Sensitive Information)

The product generates an error message that includes sensitive information about its environment, users, or associated data.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 390 (Detection of Error Condition Without Action)

The product detects a specific error, but takes no actions to handle the error.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 391 (Unchecked Error Condition)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 460 (Improper Cleanup on Thrown Exception)

The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 497 (Exposure of Sensitive System Information to an Unauthorized Control Sphere)

The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 544 (Missing Standardized Error Handling Mechanism)

The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 703 (Improper Check or Handling of Exceptional Conditions)

The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 705 (Incorrect Control Flow Scoping)

The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 754 (Improper Check for Unusual or Exceptional Conditions)

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 755 (Improper Handling of Exceptional Conditions)

The product does not handle or incorrectly handles an exceptional condition.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP) - (881)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 881 (CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP))

Weaknesses in this category are related to rules in the Object Oriented Programming (OOP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 14 - Concurrency (CON) - (882)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON))

Weaknesses in this category are related to rules in the Concurrency (CON) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 366 (Race Condition within a Thread)

If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 404 (Improper Resource Shutdown or Release)

The product does not release or incorrectly releases a resource before it is made available for re-use.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 488 (Exposure of Data Element to Wrong Session)

The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 772 (Missing Release of Resource after Effective Lifetime)

The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.

Category - a CWE entry that contains a set of other entries that share a common characteristic.CERT C++ Secure Coding Section 49 - Miscellaneous (MSC) - (883)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC))

Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 116 (Improper Encoding or Escaping of Output)

The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.Output SanitizationOutput ValidationOutput Encoding

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 14 (Compiler Removal of Code to Clear Buffers)

Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 176 (Improper Handling of Unicode Encoding)

The product does not properly handle when an input contains Unicode encoding.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 20 (Improper Input Validation)

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 327 (Use of a Broken or Risky Cryptographic Algorithm)

The product uses a broken or risky cryptographic algorithm or protocol.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 330 (Use of Insufficiently Random Values)

The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 480 (Use of Incorrect Operator)

The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 482 (Comparing instead of Assigning)

The code uses an operator for comparison when the intention was to perform an assignment.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 561 (Dead Code)

The product contains dead code, which can never be executed.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 563 (Assignment to Variable without Use)

The variable's value is assigned but never used, making it a dead store.Unused Variable

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 570 (Expression is Always False)

The product contains an expression that will always evaluate to false.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 571 (Expression is Always True)

The product contains an expression that will always evaluate to true.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 697 (Incorrect Comparison)

The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 704 (Incorrect Type Conversion or Cast)

The product does not correctly convert an object, resource, or structure from one type to a different type.

Notes

Relationship

The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.

References

[REF-847] The Software Engineering Institute. "SEI CERT C++ Coding Standard". <https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682>.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	95	out of	933
Categories	15	out of	352
Views	0	out of	47
Total	110	out of	1332

Content History

Submissions
Submission Date	Submitter	Organization
2011-08-04	CWE Content Team	MITRE
2011-08-04
Modifications
Modification Date	Modifier	Organization
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Description, Maintenance_Notes, Name, References
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated View_Audience
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Description, Maintenance_Notes
Previous Entry Names
Change Date	Previous Entry Name
2019-01-03	Weaknesses Addressed by the CERT C++ Secure Coding Standard

View Components

Weakness ID: 770

Abstraction: Base
Structure: Simple

View customized information:

Description

Extended Description

Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - 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.	665	Improper Initialization
ChildOf	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.	400	Uncontrolled Resource Consumption
ParentOf	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.	774	Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOf	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.	789	Memory Allocation with Excessive Size Value
ParentOf	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.	1325	Improperly Controlled Sequential Memory Allocation
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	20	Improper Input Validation

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	840	Business Logic Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	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.	400	Uncontrolled Resource Consumption

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Modes Of Introduction

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.

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Often Prevalent)

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other) When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This code allocates a socket and forks each time it receives a new connection.

(bad code)

Example Language: C

sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {

newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();

}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.

Example 2

In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)

Example Language: C

int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {

printf("Unable to open socket connection");
return(FAIL);

}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {

if (openFileToWrite(filename) > 0) {

while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){

if (!(writeToFile(buffer) > 0))

break;

}

}
closeFile();

}
closeSocket(socket);

}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.

Example 3

In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)

Example Language: C

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{

char *body;

int length = getMessageLength(message[0]);

if (length > 0) {

body = &message[1][0];
processMessageBody(body);
return(SUCCESS);

}
else {

printf("Unable to process message; invalid message length");
return(FAIL);

}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)

Example Language: C

unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}

Example 4

In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)

Example Language: Java

public void acceptConnections() {

try {

ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {

Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();

}
serverSocket.close();

} catch (IOException ex) {...}

}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)

Example Language: Java

public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {

try {

ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {

hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);

}
serverSocket.close();

} catch (IOException ex) {...}

}

Example 5

An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:

[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.

Example 6

Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

(bad code)

Example Language: C

bar connection() {

foo = malloc(1024);
return foo;

}

endConnection(bar foo) {

free(foo);

}

int main() {

while(1) {

foo=connection();

}

endConnection(foo)

}

Observed Examples

Reference	Description
CVE-2022-21668	Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
CVE-2009-4017	Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
CVE-2009-2726	Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
CVE-2009-2540	Large integer value for a length property in an object causes a large amount of memory allocation.
CVE-2009-2054	Product allows exhaustion of file descriptors when processing a large number of TCP packets.
CVE-2008-5180	Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
CVE-2008-1700	Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CVE-2005-4650	CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
CVE-2020-15100	web application scanner attempts to read an excessively large file created by a user, causing process termination
CVE-2020-7218	Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service

Potential Mitigations

Phase: Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Phase: Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Phase: Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Phase: Implementation

Strategy: Input Validation

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

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

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

Note: This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Phase: Architecture and Design

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

Phase: Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:

recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays

uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Phase: Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Ensure that all failures in resource allocation place the system into a safe posture.

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

Detection Methods

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

Memberships

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.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	857	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	858	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	861	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	985	SFP Secondary Cluster: Unrestricted Consumption
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1147	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1148	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1152	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)

Notes

Relationship

This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)	FIO04-J	Close resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)	SER12-J	Avoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011)	MSC05-J	Do not exhaust heap space

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-125	Flooding
CAPEC-130	Excessive Allocation
CAPEC-147	XML Ping of the Death
CAPEC-197	Exponential Data Expansion
CAPEC-229	Serialized Data Parameter Blowup
CAPEC-230	Serialized Data with Nested Payloads
CAPEC-231	Oversized Serialized Data Payloads
CAPEC-469	HTTP DoS
CAPEC-482	TCP Flood
CAPEC-486	UDP Flood
CAPEC-487	ICMP Flood
CAPEC-488	HTTP Flood
CAPEC-489	SSL Flood
CAPEC-490	Amplification
CAPEC-491	Quadratic Data Expansion
CAPEC-493	SOAP Array Blowup
CAPEC-494	TCP Fragmentation
CAPEC-495	UDP Fragmentation
CAPEC-496	ICMP Fragmentation
CAPEC-528	XML Flood

References

[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.

[REF-387] D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.

[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23. <http://blogs.sans.org/appsecstreetfighter/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2009-05-13	CWE Content Team	MITRE
2009-05-13
Modifications
Modification Date	Modifier	Organization
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Related_Attack_Patterns
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Demonstrative_Examples, Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Detection_Factors, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Related_Attack_Patterns
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors

Weakness ID: 805

Abstraction: Base
Structure: Simple

View customized information:

Description

The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.

Extended Description

When the length value exceeds the size of the destination, a buffer overflow could occur.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	806	Buffer Access Using Size of Source Buffer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	130	Improper Handling of Length Parameter Inconsistency

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Read Memory; Modify Memory; Execute Unauthorized Code or Commands Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.
Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU) Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: 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);
...

Observed Examples

Reference	Description
CVE-2011-1959	Chain: large length value causes buffer over-read (CWE-126)
CVE-2011-1848	Use of packet length field to make a calculation, then copy into a fixed-size buffer
CVE-2011-0105	Chain: retrieval of length value from an uninitialized memory location
CVE-2011-0606	Crafted length value in document reader leads to buffer overflow
CVE-2011-0651	SSL server overflow when the sum of multiple length fields exceeds a given value
CVE-2010-4156	Language interpreter API function doesn't validate length argument, leading to information exposure

Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

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

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the product using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

Note: This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

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

Double check that the buffer is as large as specified.

When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.

If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phase: Architecture and Design

Phase: Operation

Strategy: Environment Hardening

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

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].

Effectiveness: Defense in Depth

Note: This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61].

Effectiveness: Defense in Depth

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses)
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Automated Static Analysis

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

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

Effectiveness: High

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

Automated Dynamic Analysis

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

Effectiveness: Moderate

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

Manual Analysis

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

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	740	CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	874	CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1160	SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	ARR38-C	Imprecise	Guarantee that library functions do not form invalid pointers

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-100	Overflow Buffers
CAPEC-256	SOAP Array Overflow

References

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Why ACLs Are Important" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.

[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.

[REF-60] "PaX". <http://en.wikipedia.org/wiki/PaX>.

[REF-741] Jason Lam. "Top 25 Series - Rank 12 - Buffer Access with Incorrect Length Value". SANS Software Security Institute. 2010-03-11. <http://blogs.sans.org/appsecstreetfighter/2010/03/11/top-25-series-rank-12-buffer-access-with-incorrect-length-value/>.

[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.

[REF-56] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.

[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>.

[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.

Content History

Submissions
Submission Date	Submitter	Organization
2010-01-15	CWE Content Team	MITRE
2010-01-15
Modifications
Modification Date	Modifier	Organization
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Demonstrative_Examples, Observed_Examples, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations, References
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Demonstrative_Examples
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Demonstrative_Examples, Potential_Mitigations
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors, Potential_Mitigations

Weakness ID: 120

Abstraction: Base
Structure: Simple

View customized information:

Description

The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.

Extended Description

A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.

Alternate Terms

Classic Buffer Overflow:	This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.
Unbounded Transfer

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	785	Use of Path Manipulation Function without Maximum-sized Buffer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	170	Improper Null Termination
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	231	Improper Handling of Extra Values
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	456	Missing Initialization of a Variable
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	123	Write-what-where Condition

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	20	Improper Input Validation

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.
Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU) Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array.

(bad code)

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

Observed Examples

Reference	Description
CVE-2000-1094	buffer overflow using command with long argument
CVE-1999-0046	buffer overflow in local program using long environment variable
CVE-2002-1337	buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
CVE-2003-0595	By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
CVE-2001-0191	By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.

Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

Effectiveness: Defense in Depth

Phase: Implementation

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

Double check that your buffer is as large as you specify.

When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.

If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phase: Implementation

Strategy: Input Validation

Phase: Architecture and Design

Phase: Operation

Strategy: Environment Hardening

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

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].

Effectiveness: Defense in Depth

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61].

Effectiveness: Defense in Depth

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

Phases: Build and Compilation; Operation

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

Phase: Implementation

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

Effectiveness: Moderate

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

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

Effectiveness: Limited

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses)
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Automated Static Analysis

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

Effectiveness: High

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

Automated Dynamic Analysis

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

Manual Analysis

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

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

Cost effective for partial coverage:

Web Application Scanner

Web Services Scanner

Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:

Fuzz Tester

Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Highly cost effective:

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

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

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Functional Areas

Memory Management

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	722	OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	726	OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	741	CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	865	2011 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	875	CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	970	SFP Secondary Cluster: Faulty Buffer Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1129	CISQ Quality Measures (2016) - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1131	CISQ Quality Measures (2016) - Security
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1161	SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)

Notes

Relationship

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

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Unbounded Transfer ('classic overflow')
7 Pernicious Kingdoms			Buffer Overflow
CLASP			Buffer overflow
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input
OWASP Top Ten 2004	A5	CWE More Specific	Buffer Overflows
CERT C Secure Coding	STR31-C	Exact	Guarantee that storage for strings has sufficient space for character data and the null terminator
WASC	7		Buffer Overflow
Software Fault Patterns	SFP8		Faulty Buffer Access
OMG ASCSM	ASCSM-CWE-120
OMG ASCRM	ASCRM-CWE-120

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-10	Buffer Overflow via Environment Variables
CAPEC-100	Overflow Buffers
CAPEC-14	Client-side Injection-induced Buffer Overflow
CAPEC-24	Filter Failure through Buffer Overflow
CAPEC-42	MIME Conversion
CAPEC-44	Overflow Binary Resource File
CAPEC-45	Buffer Overflow via Symbolic Links
CAPEC-46	Overflow Variables and Tags
CAPEC-47	Buffer Overflow via Parameter Expansion
CAPEC-67	String Format Overflow in syslog()
CAPEC-8	Buffer Overflow in an API Call
CAPEC-9	Buffer Overflow in Local Command-Line Utilities
CAPEC-92	Forced Integer Overflow

References

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.

[REF-56] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.

[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.

[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.

[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.

[REF-60] "PaX". <http://en.wikipedia.org/wiki/PaX>.

[REF-74] Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.

[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.

[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.

[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.

[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	PLOVER
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10	CWE Content Team	MITRE
2008-10-10	Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Description
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations, References
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated References, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences, Potential_Mitigations
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Alternate_Terms, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Demonstrative_Examples, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Potential_Mitigations
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Common_Consequences, Description
Previous Entry Names
Change Date	Previous Entry Name
2008-10-14	Unbounded Transfer ('Classic Buffer Overflow')

Weakness ID: 362

Abstraction: Class
Structure: Simple

View customized information:

Description

Extended Description

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

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

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

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

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

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

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	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.	691	Insufficient Control Flow Management
ParentOf	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.	364	Signal Handler Race Condition
ParentOf	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.	366	Race Condition within a Thread
ParentOf	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.	367	Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOf	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.	368	Context Switching Race Condition
ParentOf	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.	421	Race Condition During Access to Alternate Channel
ParentOf	Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.	689	Permission Race Condition During Resource Copy
ParentOf	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.	1223	Race Condition for Write-Once Attributes
ParentOf	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.	1298	Hardware Logic Contains Race Conditions
CanFollow	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.	662	Improper Synchronization

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ParentOf	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.	367	Time-of-check Time-of-use (TOCTOU) Race Condition

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

Languages

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other) When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion (CWE-400).
Availability	Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Confidentiality Integrity	Technical Impact: Read Files or Directories; Read Application Data When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

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

(bad code)

Example Language: Perl

$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {

FatalError("Bad Transfer Amount");

}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {

FatalError("Insufficient Funds");

}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

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

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

(attack code)

Example Language: Other

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

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

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

Example 2

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

(bad code)

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

Observed Examples

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

Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Detection Methods

Black Box

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

White Box

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

Automated Dynamic Analysis

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

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

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Cost effective for partial coverage:

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

Cost effective for partial coverage:

Web Application Scanner

Web Services Scanner

Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Highly cost effective:

Framework-based Fuzzer

Cost effective for partial coverage:

Fuzz Tester

Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

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

Highly cost effective:

Manual Source Code Review (not inspections)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

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

Highly cost effective:

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

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

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	743	CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	801	2010 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	852	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	882	CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	988	SFP Secondary Cluster: Race Condition Window
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1142	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1376	ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses

Notes

Research Gap

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

Research Gap

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

Research Gap

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

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Race Conditions
The CERT Oracle Secure Coding Standard for Java (2011)	VNA03-J		Do not assume that a group of calls to independently atomic methods is atomic

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-26	Leveraging Race Conditions
CAPEC-29	Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.

[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <http://www.ddj.com/cpp/184403766>.

[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.

[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.

[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.

[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.

[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <http://www.blakewatts.com/namedpipepaper.html>.

[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.

[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.

[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <http://blogs.sans.org/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>.

[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	PLOVER
2006-07-19
Contributions
Contribution Date	Contributor	Organization
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples, Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, References, Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, References, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Observed_Examples, References
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Observed_Examples, Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Common_Consequences, Description
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Race Conditions

2010-12-13	Race Condition

Weakness ID: 390

Abstraction: Base
Structure: Simple

View customized information:

Description

The product detects a specific error, but takes no actions to handle the error.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	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.	755	Improper Handling of Exceptional Conditions
PeerOf	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.	600	Uncaught Exception in Servlet
CanPrecede	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.	401	Missing Release of Memory after Effective Lifetime

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	389	Error Conditions, Return Values, Status Codes

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1020	Verify Message Integrity

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Integrity Other	Technical Impact: Varies by Context; Unexpected State; Alter Execution Logic An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.

(bad code)

Example Language: C

foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {

//We do nothing so we just ignore the error.

}

The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.

Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code.

(good code)

Example Language: C

foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {

printf("Malloc failed to allocate memory resources");
return -1;

}

Example 2

In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed.

(bad code)

Example Language: C++

char* readfile (char *filename) {

try {

// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {

throw "Unable to open file " + filename;

}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {

throw "Unable to read from file " + filename;

}

infile.close();

return buffer;

}
catch (...) {

/* bug: insert code to handle this later */

}

The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following C++ example contains two catch statements. The first of these will catch a specific error thrown within the try block, and the second catch statement will catch all other errors from within the catch block. Both catch statements will notify the user that an error has occurred, close the file, and rethrow to the block that called the readFile() method for further handling or possible termination of the program.

(good code)

Example Language: C++

char* readFile (char *filename) {

try {

// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {

throw "Unable to open file " + filename;

throw "Unable to read from file " + filename;

}
infile.close();

return buffer;

}
catch (char *str) {

printf("Error: %s \n", str);
infile.close();
throw str;

}
catch (...) {

printf("Error occurred trying to read from file \n");
infile.close();
throw;

}

Example 3

In the following Java example the method readFile will read the file whose name is provided in the input parameter and will return the contents of the file in a String object. The constructor of the FileReader object and the read method call may throw exceptions and therefore must be within a try/catch block. While the catch statement in this example will catch thrown exceptions in order for the method to compile, no processing is performed to handle the thrown exceptions. Catch statements that do not perform any processing will have unexpected results. In this case, this will result in the return of a null String.

(bad code)

Example Language: Java

public String readFile(String filename) {

String retString = null;
try {

// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char[] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (Exception ex) {

/* do nothing, but catch so it'll compile... */

}
return retString;

}

The catch statement should contain statements that either attempt to fix the problem, notify the user that an exception has been raised and continue processing, or perform some cleanup and gracefully terminate the program. The following Java example contains three catch statements. The first of these will catch the FileNotFoundException that may be thrown by the FileReader constructor called within the try/catch block. The second catch statement will catch the IOException that may be thrown by the read method called within the try/catch block. The third catch statement will catch all other exceptions thrown within the try block. For all catch statements the user is notified that the exception has been thrown and the exception is rethrown to the block that called the readFile() method for further processing or possible termination of the program. Note that with Java it is usually good practice to use the getMessage() method of the exception class to provide more information to the user about the exception raised.

(good code)

Example Language: Java

public String readFile(String filename) throws FileNotFoundException, IOException, Exception {

String retString = null;
try {

// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char [] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (FileNotFoundException ex) {

System.err.println ("Error: FileNotFoundException opening the input file: " + filename );
System.err.println ("" + ex.getMessage() );
throw new FileNotFoundException(ex.getMessage());

} catch (IOException ex) {

System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() );
throw new IOException(ex);

} catch (Exception ex) {

System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() );
throw new Exception(ex);

}
return retString;

}

Potential Mitigations

Phase: Implementation

Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Phase: Implementation

If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.

Phase: Testing

Subject the product to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	728	OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	851	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	880	CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1306	CISQ Quality Measures - Reliability

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
CLASP		Improper error handling
The CERT Oracle Secure Coding Standard for Java (2011)	ERR00-J	Do not suppress or ignore checked exceptions
Software Fault Patterns	SFP4	Unchecked Status Condition

References

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	CLASP
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, References, Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns, Taxonomy_Mappings
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Type
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Improper Error Handling

Common Weakness Enumeration

CWE VIEW: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)

View Components

CWE-464: Addition of Data Structure Sentinel

CWE-770: Allocation of Resources Without Limits or Throttling

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

CWE-563: Assignment to Variable without Use

CWE-805: Buffer Access with Incorrect Length Value

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

CWE CATEGORY: CERT C++ Secure Coding Section 01 - Preprocessor (PRE)

CWE CATEGORY: CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL)

CWE CATEGORY: CERT C++ Secure Coding Section 03 - Expressions (EXP)

CWE CATEGORY: CERT C++ Secure Coding Section 04 - Integers (INT)

CWE CATEGORY: CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)

CWE CATEGORY: CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)

CWE CATEGORY: CERT C++ Secure Coding Section 07 - Characters and Strings (STR)

CWE CATEGORY: CERT C++ Secure Coding Section 08 - Memory Management (MEM)

CWE CATEGORY: CERT C++ Secure Coding Section 09 - Input Output (FIO)

CWE CATEGORY: CERT C++ Secure Coding Section 10 - Environment (ENV)

CWE CATEGORY: CERT C++ Secure Coding Section 11 - Signals (SIG)

CWE CATEGORY: CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)

CWE CATEGORY: CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP)

CWE CATEGORY: CERT C++ Secure Coding Section 14 - Concurrency (CON)

CWE CATEGORY: CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)

CWE-482: Comparing instead of Assigning

CWE-14: Compiler Removal of Code to Clear Buffers

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

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

CWE-561: Dead Code

CWE-390: Detection of Error Condition Without Action

CWE-369: Divide By Zero

CWE-415: Double Free