CWE - VIEW SLICE: CWE-1154: Weaknesses Addressed by the SEI CERT C Coding Standard (4.10)

CWE VIEW: Weaknesses Addressed by the SEI CERT C Coding Standard

View ID: 1154

Type: Graph

Downloads: Booklet | CSV | XML

Objective

CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the online wiki that reflects that current rules and recommendations of the SEI CERT C Coding Standard.

Audience

Stakeholder	Description
Software Developers	By following the SEI CERT C 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 SEI CERT C 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

1154 - Weaknesses Addressed by the SEI CERT C Coding Standard

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 01. Preprocessor (PRE) - (1155)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1155 (SEI CERT C Coding Standard - Guidelines 01. Preprocessor (PRE))

Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) section of the SEI CERT C Coding Standard.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL) - (1156)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1156 (SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL))

Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT C Coding Standard.

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1156 (SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) > 562 (Return of Stack Variable Address)

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP) - (1157)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP))

Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT C Coding Standard.

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.Reliance on Undefined, Unspecified, or Implementation-Defined Behavior - (758)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 908 (Use of Uninitialized Resource)

The product uses or accesses a resource that has not been initialized.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 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

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)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 628 (Function Call with Incorrectly Specified Arguments)

The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 685 (Function Call With Incorrect Number of Arguments)

The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 843 (Access of Resource Using Incompatible Type ('Type Confusion'))

The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.Object Type Confusion

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 704 (Incorrect Type Conversion or Cast)

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

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 125 (Out-of-bounds Read)

The product reads data past the end, or before the beginning, of the intended buffer.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 480 (Use of Incorrect Operator)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1157 (SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) > 481 (Assigning instead of Comparing)

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

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 04. Integers (INT) - (1158)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT))

Weaknesses in this category are related to the rules and recommendations in the Integers (INT) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 191 (Integer Underflow (Wrap or Wraparound))

The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.Integer underflow

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 680 (Integer Overflow to Buffer Overflow)

The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 704 (Incorrect Type Conversion or Cast)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 194 (Unexpected Sign Extension)

The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 195 (Signed to Unsigned Conversion Error)

The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 369 (Divide By Zero)

The product divides a value by zero.

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)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1158 (SEI CERT C Coding Standard - Guidelines 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP) - (1159)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1159 (SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP))

Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1159 (SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) > 682 (Incorrect Calculation)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1159 (SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1159 (SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) > 681 (Incorrect Conversion between Numeric Types)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1159 (SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR) - (1160)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR))

Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) section of the SEI CERT C Coding Standard.

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 129 (Improper Validation of Array Index)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 786 (Access of Memory Location Before Start of Buffer)

The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 123 (Write-what-where Condition)

Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 125 (Out-of-bounds Read)

The product reads data past the end, or before the beginning, of the intended buffer.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 469 (Use of Pointer Subtraction to Determine Size)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 121 (Stack-based Buffer Overflow)

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).Stack Overflow

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 805 (Buffer Access with Incorrect Length Value)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1160 (SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) > 468 (Incorrect Pointer Scaling)

In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR) - (1161)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR))

Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 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

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) > 121 (Stack-based Buffer Overflow)

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).Stack Overflow

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) > 122 (Heap-based Buffer Overflow)

A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) > 123 (Write-what-where Condition)

Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) > 125 (Out-of-bounds Read)

The product reads data past the end, or before the beginning, of the intended buffer.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1161 (SEI CERT C Coding Standard - Guidelines 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM) - (1162)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM))

Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 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

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.Operation on a Resource after Expiration or Release - (672)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 672 (Operation on a Resource after Expiration or Release)

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

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.Operation on Resource in Wrong Phase of Lifetime - (666)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 666 (Operation on Resource in Wrong Phase of Lifetime)

The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 415 (Double Free)

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

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Missing Release of Memory after Effective Lifetime - (401)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 401 (Missing Release of Memory after Effective Lifetime)

The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 459 (Incomplete Cleanup)

The product does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 771 (Missing Reference to Active Allocated Resource)

The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 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().

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 680 (Integer Overflow to Buffer Overflow)

The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 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.

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.Memory Allocation with Excessive Size Value - (789)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 789 (Memory Allocation with Excessive Size Value)

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.Stack Exhaustion

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1162 (SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) > 190 (Integer Overflow or Wraparound)

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO) - (1163)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO))

Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 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).

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 664 (Improper Control of a Resource Through its Lifetime)

The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 459 (Incomplete Cleanup)

The product does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 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.

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.Missing Reference to Active File Descriptor or Handle - (773)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 773 (Missing Reference to Active File Descriptor or Handle)

The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.

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.Missing Release of File Descriptor or Handle after Effective Lifetime - (775)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 775 (Missing Release of File Descriptor or Handle after Effective Lifetime)

The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 771 (Missing Reference to Active Allocated Resource)

The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 910 (Use of Expired File Descriptor)

The product uses or accesses a file descriptor after it has been closed.Stale file descriptor

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.Operation on Resource in Wrong Phase of Lifetime - (666)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 666 (Operation on Resource in Wrong Phase of Lifetime)

The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.

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.Operation on a Resource after Expiration or Release - (672)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 672 (Operation on a Resource after Expiration or Release)

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 686 (Function Call With Incorrect Argument Type)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1163 (SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) > 685 (Function Call With Incorrect Number of Arguments)

The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 10. Environment (ENV) - (1165)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1165 (SEI CERT C Coding Standard - Guidelines 10. Environment (ENV))

Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1165 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1165 (SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1165 (SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1165 (SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) > 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.SEI CERT C Coding Standard - Guidelines 11. Signals (SIG) - (1166)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1166 (SEI CERT C Coding Standard - Guidelines 11. Signals (SIG))

Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) section of the SEI CERT C Coding Standard.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Signal Handler Use of a Non-reentrant Function - (479)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1166 (SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)) > 479 (Signal Handler Use of a Non-reentrant Function)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1166 (SEI CERT C Coding Standard - Guidelines 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.SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR) - (1167)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR))

Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) > 456 (Missing Initialization of a Variable)

The product does not initialize critical variables, which causes the execution environment to use unexpected values.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) > 391 (Unchecked Error Condition)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) > 253 (Incorrect Check of Function Return Value)

The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) > 676 (Use of Potentially Dangerous Function)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1167 (SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 13. Application Programming Interfaces (API) - (1168)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1168 (SEI CERT C Coding Standard - Guidelines 13. Application Programming Interfaces (API))

Weaknesses in this category are related to the rules and recommendations in the Application Programming Interfaces (API) section of the SEI CERT C Coding Standard.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON) - (1169)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1169 (SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON))

Weaknesses in this category are related to the rules and recommendations in the Concurrency (CON) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1169 (SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) > 667 (Improper Locking)

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1169 (SEI CERT C Coding Standard - Guidelines 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1169 (SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1169 (SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) > 330 (Use of Insufficiently Random Values)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1169 (SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) > 377 (Insecure Temporary File)

Creating and using insecure temporary files can leave application and system data vulnerable to attack.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC) - (1170)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC))

Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT C Coding Standard.

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) > 327 (Use of a Broken or Risky Cryptographic Algorithm)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) > 338 (Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))

The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) > 331 (Insufficient Entropy)

The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1170 (SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 50. POSIX (POS) - (1171)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS))

Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 170 (Improper Null Termination)

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

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 242 (Use of Inherently Dangerous Function)

The product calls a function that can never be guaranteed to work safely.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 363 (Race Condition Enabling Link Following)

The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 696 (Incorrect Behavior Order)

The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 273 (Improper Check for Dropped Privileges)

The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 667 (Improper Locking)

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 391 (Unchecked Error Condition)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1171 (SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) > 253 (Incorrect Check of Function Return Value)

The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.

Category - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) - (1172)

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1172 (SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) )

Weaknesses in this category are related to the rules and recommendations in the Microsoft Windows (WIN) section of the SEI CERT C Coding Standard.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1172 (SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) ) > 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.

1154 (Weaknesses Addressed by the SEI CERT C Coding Standard) > 1172 (SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) ) > 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().

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-598] The Software Engineering Institute. "SEI CERT C Coding Standard". <https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard>.

View Metrics

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

Content History

Submissions
Submission Date	Submitter	Organization
2018-12-18	CWE Content Team	MITRE
2018-12-18
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated View_Audience

View Components

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

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

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
Implementation

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

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

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

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

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

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

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

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

Phase: Architecture and Design

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

Abstraction: Pillar
Structure: Simple

View customized information:

Description

The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.

Extended Description

Resources often have explicit instructions on how to be created, used and destroyed. When code does not follow these instructions, it can lead to unexpected behaviors and potentially exploitable states.

Even without explicit instructions, various principles are expected to be adhered to, such as "Do not use an object until after its creation is complete," or "do not use an object after it has been slated for destruction."

Relationships

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

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).	1000	Research Concepts
ParentOf	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.	118	Incorrect Access of Indexable Resource ('Range Error')
ParentOf	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.	221	Information Loss or Omission
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.	372	Incomplete Internal State Distinction
ParentOf	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	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.	404	Improper Resource Shutdown or Release
ParentOf	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.	405	Asymmetric Resource Consumption (Amplification)
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.	410	Insufficient Resource Pool
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.	471	Modification of Assumed-Immutable Data (MAID)
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.	487	Reliance on Package-level Scope
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.	495	Private Data Structure Returned From A Public Method
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.	496	Public Data Assigned to Private Array-Typed Field
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.	501	Trust Boundary Violation
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.	580	clone() Method Without super.clone()
ParentOf	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.	610	Externally Controlled Reference to a Resource in Another Sphere
ParentOf	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
ParentOf	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
ParentOf	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.	666	Operation on Resource in Wrong Phase of Lifetime
ParentOf	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.	668	Exposure of Resource to Wrong Sphere
ParentOf	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.	669	Incorrect Resource Transfer Between Spheres
ParentOf	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.	673	External Influence of Sphere Definition
ParentOf	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.	704	Incorrect Type Conversion or Cast
ParentOf	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.	706	Use of Incorrectly-Resolved Name or Reference
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.	911	Improper Update of Reference Count
ParentOf	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.	913	Improper Control of Dynamically-Managed Code Resources
ParentOf	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.	922	Insecure Storage of Sensitive Information
ParentOf	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.	1229	Creation of Emergent Resource
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.	1250	Improper Preservation of Consistency Between Independent Representations of Shared State
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.	1329	Reliance on Component That is Not Updateable

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Other

Potential Mitigations

Phase: Testing

Use Static analysis tools to check for unreleased resources.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	984	SFP Secondary Cluster: Life Cycle
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1163	SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)

Notes

Maintenance

More work is needed on this entry and its children. There are perspective/layering issues; for example, one breakdown is based on lifecycle phase (CWE-404, CWE-665), while other children are independent of lifecycle, such as CWE-400. Others do not specify as many bases or variants, such as CWE-704, which primarily covers numbers at this stage.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	FIO39-C	CWE More Abstract	Do not alternately input and output from a stream without an intervening flush or positioning call

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-196	Session Credential Falsification through Forging
CAPEC-21	Exploitation of Trusted Identifiers
CAPEC-60	Reusing Session IDs (aka Session Replay)
CAPEC-61	Session Fixation
CAPEC-62	Cross Site Request Forgery

Content History

Submissions
Submission Date	Submitter	Organization
2008-04-11	CWE Content Team	MITRE
2008-04-11
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Maintenance_Notes, Relationships, Type
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Related_Attack_Patterns
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Description, Name, Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Description, Relationships
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Related_Attack_Patterns, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Relationships
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
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, Relationships, Type
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
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-03-15	CWE Content Team	MITRE
2021-03-15	updated Maintenance_Notes, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Relationships
Previous Entry Names
Change Date	Previous Entry Name
2009-05-27	Insufficient Control of a Resource Through its Lifetime

Weakness ID: 20

Abstraction: Class
Structure: Simple

View customized information:

Description

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.

Extended Description

Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.

Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to another component. Other techniques exist as well (see CWE-138 for more examples.)

Input validation can be applied to:

raw data - strings, numbers, parameters, file contents, etc.
metadata - information about the raw data, such as headers or size

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data.

Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

specified quantities such as size, length, frequency, price, rate, number of operations, time, etc.
implied or derived quantities, such as the actual size of a file instead of a specified size
indexes, offsets, or positions into more complex data structures
symbolic keys or other elements into hash tables, associative arrays, etc.
well-formedness, i.e. syntactic correctness - compliance with expected syntax
lexical token correctness - compliance with rules for what is treated as a token
specified or derived type - the actual type of the input (or what the input appears to be)
consistency - between individual data elements, between raw data and metadata, between references, etc.
conformance to domain-specific rules, e.g. business logic
equivalence - ensuring that equivalent inputs are treated the same
authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the data

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation.

Note that "input validation" has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation.

Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person's last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

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.	707	Improper Neutralization
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.	179	Incorrect Behavior Order: Early Validation
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.	622	Improper Validation of Function Hook Arguments
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.	1173	Improper Use of Validation Framework
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.	1284	Improper Validation of Specified Quantity in Input
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.	1285	Improper Validation of Specified Index, Position, or Offset in Input
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.	1286	Improper Validation of Syntactic Correctness of Input
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.	1287	Improper Validation of Specified Type of Input
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.	1288	Improper Validation of Consistency within Input
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.	1289	Improper Validation of Unsafe Equivalence in Input
PeerOf	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.	345	Insufficient Verification of Data Authenticity
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.	22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
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.	41	Improper Resolution of Path Equivalence
CanPrecede	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.	74	Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CanPrecede	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
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.	770	Allocation of Resources Without Limits or Throttling

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

Nature	Type	ID	Name
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.	129	Improper Validation of Array Index
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.	1284	Improper Validation of Specified Quantity in Input

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.	1019	Validate Inputs

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

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.	15	External Control of System or Configuration Setting
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.	73	External Control of File Name or Path
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.	102	Struts: Duplicate Validation Forms
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.	103	Struts: Incomplete validate() Method Definition
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.	104	Struts: Form Bean Does Not Extend Validation Class
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.	105	Struts: Form Field Without Validator
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.	106	Struts: Plug-in Framework not in Use
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.	107	Struts: Unused Validation Form
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.	108	Struts: Unvalidated Action Form
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.	109	Struts: Validator Turned Off
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.	110	Struts: Validator Without Form Field
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.	111	Direct Use of Unsafe JNI
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.	112	Missing XML Validation
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.	113	Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
ParentOf	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.	114	Process Control
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.	117	Improper Output Neutralization for Logs
ParentOf	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	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.	120	Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
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.	134	Use of Externally-Controlled Format String
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.	170	Improper Null Termination
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.	190	Integer Overflow or Wraparound
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.	466	Return of Pointer Value Outside of Expected Range
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.	470	Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
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

Modes Of Introduction

Phase

Note

Architecture and Design

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

If a programmer believes that an attacker cannot modify certain inputs, then the programmer might not perform any input validation at all. For example, in web applications, many programmers believe that cookies and hidden form fields can not be modified from a web browser (CWE-472), although they can be altered using a proxy or a custom program. In a client-server architecture, the programmer might assume that client-side security checks cannot be bypassed, even when a custom client could be written that skips those checks (CWE-602).

Applicable Platforms

Languages

Class: Not Language-Specific (Often Prevalent)

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory) An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.
Confidentiality	Technical Impact: Read Memory; Read Files or Directories An attacker could read confidential data if they are able to control resource references.
Integrity Confidentiality Availability	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated.

(bad code)

Example Language: Java

...
public static final double price = 20.00;
int quantity = currentUser.getAttribute("quantity");
double total = price * quantity;
chargeUser(total);
...

The user has no control over the price variable, however the code does not prevent a negative value from being specified for quantity. If an attacker were to provide a negative value, then the user would have their account credited instead of debited.

Example 2

This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares.

(bad code)

Example Language: C

...
#define MAX_DIM 100
...
/* board dimensions */

int m,n, error;
board_square_t *board;
printf("Please specify the board height: \n");
error = scanf("%d", &m);
if ( EOF == error ){

die("No integer passed: Die evil hacker!\n");

}
printf("Please specify the board width: \n");
error = scanf("%d", &n);
if ( EOF == error ){

die("No integer passed: Die evil hacker!\n");

}
if ( m > MAX_DIM || n > MAX_DIM ) {

die("Value too large: Die evil hacker!\n");

}
board = (board_square_t*) malloc( m * n * sizeof(board_square_t));
...

While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program.

Example 3

The following example shows a PHP application in which the programmer attempts to display a user's birthday and homepage.

(bad code)

Example Language: PHP

$birthday = $_GET['birthday'];
$homepage = $_GET['homepage'];
echo "Birthday: $birthday<br>Homepage: <a href=$homepage>click here</a>"

The programmer intended for $birthday to be in a date format and $homepage to be a valid URL. However, since the values are derived from an HTTP request, if an attacker can trick a victim into clicking a crafted URL with <script> tags providing the values for birthday and / or homepage, then the script will run on the client's browser when the web server echoes the content. Notice that even if the programmer were to defend the $birthday variable by restricting input to integers and dashes, it would still be possible for an attacker to provide a string of the form:

(attack code)

2009-01-09--

If this data were used in a SQL statement, it would treat the remainder of the statement as a comment. The comment could disable other security-related logic in the statement. In this case, encoding combined with input validation would be a more useful protection mechanism.

Furthermore, an XSS (CWE-79) attack or SQL injection (CWE-89) are just a few of the potential consequences when input validation is not used. Depending on the context of the code, CRLF Injection (CWE-93), Argument Injection (CWE-88), or Command Injection (CWE-77) may also be possible.

Example 4

The following example takes a user-supplied value to allocate an array of objects and then operates on the array.

(bad code)

Example Language: Java

private void buildList ( int untrustedListSize ){

if ( 0 > untrustedListSize ){

die("Negative value supplied for list size, die evil hacker!");

}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();

}

This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown.

Example 5

This Android application has registered to handle a URL when sent an intent:

(bad code)

Example Language: Java

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {

@Override
public void onReceive(Context context, Intent intent) {

if("com.example.URLHandler.openURL".equals(intent.getAction())) {

String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}

}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

Observed Examples

Reference	Description
CVE-2021-30860	Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
CVE-2021-30663	Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
CVE-2021-22205	Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.
CVE-2021-21220	Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), as exploited in the wild per CISA KEV.
CVE-2020-9054	Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
CVE-2020-3452	Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.
CVE-2020-3161	Improper input validation of HTTP requests in IP phone, as exploited in the wild per CISA KEV.
CVE-2020-3580	Chain: improper input validation (CWE-20) in firewall product leads to XSS (CWE-79), as exploited in the wild per CISA KEV.
CVE-2021-37147	Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
CVE-2008-5305	Eval injection in Perl program using an ID that should only contain hyphens and numbers.
CVE-2008-2223	SQL injection through an ID that was supposed to be numeric.
CVE-2008-3477	lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.
CVE-2008-3843	insufficient validation enables XSS
CVE-2008-3174	driver in security product allows code execution due to insufficient validation
CVE-2007-3409	infinite loop from DNS packet with a label that points to itself
CVE-2006-6870	infinite loop from DNS packet with a label that points to itself
CVE-2008-1303	missing parameter leads to crash
CVE-2007-5893	HTTP request with missing protocol version number leads to crash
CVE-2006-6658	request with missing parameters leads to information exposure
CVE-2008-4114	system crash with offset value that is inconsistent with packet size
CVE-2006-3790	size field that is inconsistent with packet size leads to buffer over-read
CVE-2008-2309	product uses a denylist to identify potentially dangerous content, allowing attacker to bypass a warning
CVE-2008-3494	security bypass via an extra header
CVE-2008-3571	empty packet triggers reboot
CVE-2006-5525	incomplete denylist allows SQL injection
CVE-2008-1284	NUL byte in theme name causes directory traversal impact to be worse
CVE-2008-0600	kernel does not validate an incoming pointer before dereferencing it
CVE-2008-1738	anti-virus product has insufficient input validation of hooked SSDT functions, allowing code execution
CVE-2008-1737	anti-virus product allows DoS via zero-length field
CVE-2008-3464	driver does not validate input from userland to the kernel
CVE-2008-2252	kernel does not validate parameters sent in from userland, allowing code execution
CVE-2008-2374	lack of validation of string length fields allows memory consumption or buffer over-read
CVE-2008-1440	lack of validation of length field leads to infinite loop
CVE-2008-1625	lack of validation of input to an IOCTL allows code execution
CVE-2008-3177	zero-length attachment causes crash
CVE-2007-2442	zero-length input causes free of uninitialized pointer
CVE-2008-5563	crash via a malformed frame structure
CVE-2008-5285	infinite loop from a long SMTP request
CVE-2008-3812	router crashes with a malformed packet
CVE-2008-3680	packet with invalid version number leads to NULL pointer dereference
CVE-2008-3660	crash via multiple "." characters in file extension

Potential Mitigations

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Phase: Implementation

Strategy: Input Validation

Effectiveness: High

Phase: Architecture and Design

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Phase: Implementation

When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.

Phase: Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

Phase: Implementation

Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.

Phase: Implementation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.

Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

Phase: Implementation

When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Detection Methods

Automated Static Analysis

Some instances of improper input validation can be detected using automated static analysis.

A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present.

Except in the cases described in the previous paragraph, automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

Manual Static Analysis

When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.

Fuzzing

Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.

Automated Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

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:

Highly cost effective:

Web Application Scanner

Web Services Scanner

Database Scanners

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

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

Highly cost effective:

Fuzz Tester

Framework-based Fuzzer

Cost effective for partial coverage:

Host Application Interface Scanner

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:

Focused Manual Spotcheck - Focused manual analysis of source

Manual Source Code Review (not inspections)

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:

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

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

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.	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.	738	CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	746	CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	747	CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf	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.	872	CERT C++ Secure Coding Section 04 - Integers (INT)
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.	883	CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	994	SFP Secondary Cluster: Tainted Input to Variable
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.	1005	7PK - Input Validation and Representation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1163	SEI CERT C Coding Standard - Guidelines 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).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
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).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1347	OWASP Top Ten 2021 Category A03:2021 - Injection
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).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1382	ICS Operations (& Maintenance): Emerging Energy Technologies
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

Mapping

Use for Mapping: Discouraged (this CWE ID should not be used to map to real-world vulnerabilities).

Rationale: CWE-20 is commonly misused in low-information vulnerability reports when lower-level CWEs could be used instead, or when more details about the vulnerability are available [REF-1287]. It is not useful for trend analysis. It is also a level-1 Class (i.e., a child of a Pillar).

Comments: consider lower-level children such as Improper Use of Validation Framework (CWE-1173) or improper validation involving specific types or properties of input such as Specified Quantity (CWE-1284); Specified Index, Position, or Offset (CWE-1285)); Syntactic Correctness (CWE-1286); Specified Type (CWE-1287); Consistency within Input (CWE-1288); or Unsafe Equivalence (CWE-1289).

Relationship

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.

Terminology

The "input validation" term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.

Some people use "input validation" as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean "checking if an input conforms to expectations without changing it." CWE uses this more narrow interpretation.

Maintenance

As of 2020, this entry is used more often than preferred, and it is a source of frequent confusion. It is being actively modified for CWE 4.1 and subsequent versions.

Maintenance

Concepts such as validation, data transformation, and neutralization are being refined, so relationships between CWE-20 and other entries such as CWE-707 may change in future versions, along with an update to the Vulnerability Theory document.

Maintenance

Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Input validation and representation
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input
CERT C Secure Coding	ERR07-C		Prefer functions that support error checking over equivalent functions that don't
CERT C Secure Coding	FIO30-C	CWE More Abstract	Exclude user input from format strings
CERT C Secure Coding	MEM10-C		Define and use a pointer validation function
WASC	20		Improper Input Handling
Software Fault Patterns	SFP25		Tainted input to variable

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-10	Buffer Overflow via Environment Variables
CAPEC-101	Server Side Include (SSI) Injection
CAPEC-104	Cross Zone Scripting
CAPEC-108	Command Line Execution through SQL Injection
CAPEC-109	Object Relational Mapping Injection
CAPEC-110	SQL Injection through SOAP Parameter Tampering
CAPEC-120	Double Encoding
CAPEC-13	Subverting Environment Variable Values
CAPEC-135	Format String Injection
CAPEC-136	LDAP Injection
CAPEC-14	Client-side Injection-induced Buffer Overflow
CAPEC-153	Input Data Manipulation
CAPEC-182	Flash Injection
CAPEC-209	XSS Using MIME Type Mismatch
CAPEC-22	Exploiting Trust in Client
CAPEC-23	File Content Injection
CAPEC-230	Serialized Data with Nested Payloads
CAPEC-231	Oversized Serialized Data Payloads
CAPEC-24	Filter Failure through Buffer Overflow
CAPEC-250	XML Injection
CAPEC-261	Fuzzing for garnering other adjacent user/sensitive data
CAPEC-267	Leverage Alternate Encoding
CAPEC-28	Fuzzing
CAPEC-3	Using Leading 'Ghost' Character Sequences to Bypass Input Filters
CAPEC-31	Accessing/Intercepting/Modifying HTTP Cookies
CAPEC-42	MIME Conversion
CAPEC-43	Exploiting Multiple Input Interpretation Layers
CAPEC-45	Buffer Overflow via Symbolic Links
CAPEC-46	Overflow Variables and Tags
CAPEC-47	Buffer Overflow via Parameter Expansion
CAPEC-473	Signature Spoof
CAPEC-52	Embedding NULL Bytes
CAPEC-53	Postfix, Null Terminate, and Backslash
CAPEC-588	DOM-Based XSS
CAPEC-63	Cross-Site Scripting (XSS)
CAPEC-64	Using Slashes and URL Encoding Combined to Bypass Validation Logic
CAPEC-664	Server Side Request Forgery
CAPEC-67	String Format Overflow in syslog()
CAPEC-7	Blind SQL Injection
CAPEC-71	Using Unicode Encoding to Bypass Validation Logic
CAPEC-72	URL Encoding
CAPEC-73	User-Controlled Filename
CAPEC-78	Using Escaped Slashes in Alternate Encoding
CAPEC-79	Using Slashes in Alternate Encoding
CAPEC-8	Buffer Overflow in an API Call
CAPEC-80	Using UTF-8 Encoding to Bypass Validation Logic
CAPEC-81	Web Server Logs Tampering
CAPEC-83	XPath Injection
CAPEC-85	AJAX Footprinting
CAPEC-88	OS Command Injection
CAPEC-9	Buffer Overflow in Local Command-Line Utilities

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

[REF-166] Jim Manico. "Input Validation with ESAPI - Very Important". 2008-08-15. <http://manicode.blogspot.com/2008/08/input-validation-with-esapi.html>.

[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

[REF-168] Joel Scambray, Mike Shema and Caleb Sima. "Hacking Exposed Web Applications, Second Edition". Input Validation Attacks. McGraw-Hill. 2006-06-05.

[REF-48] Jeremiah Grossman. "Input validation or output filtering, which is better?". 2007-01-30. <http://jeremiahgrossman.blogspot.com/2007/01/input-validation-or-output-filtering.html>.

[REF-170] Kevin Beaver. "The importance of input validation". 2006-09-06. <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1214373,00.html>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 10, "All Input Is Evil!" Page 341. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-1109] "LANGSEC: Language-theoretic Security". <http://langsec.org/>.

[REF-1110] "LangSec: Recognition, Validation, and Compositional Correctness for Real World Security". <http://langsec.org/bof-handout.pdf>.

[REF-1111] Sergey Bratus, Lars Hermerschmidt, Sven M. Hallberg, Michael E. Locasto, Falcon D. Momot, Meredith L. Patterson and Anna Shubina. "Curing the Vulnerable Parser: Design Patterns for Secure Input Handling". USENIX ;login:. 2017. <https://www.usenix.org/system/files/login/articles/login_spring17_08_bratus.pdf>.

[REF-1287] MITRE. "Supplemental Details - 2022 CWE Top 25". Details of Problematic Mappings. 2022-06-28. <https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	7 Pernicious Kingdoms
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
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 Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Description, Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Related_Attack_Patterns
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Demonstrative_Examples, Maintenance_Notes, Modes_of_Introduction, Observed_Examples, Relationships, Research_Gaps, Terminology_Notes
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings
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 Potential_Mitigations, Research_Gaps, Terminology_Notes
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Demonstrative_Examples, Description
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Observed_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Applicable_Platforms, Common_Consequences, Relationship_Notes
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
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Relationships
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Demonstrative_Examples, Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Related_Attack_Patterns, Relationships
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns, Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, 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 Related_Attack_Patterns, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Terminology_Notes
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Description, Potential_Mitigations
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Related_Attack_Patterns, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated 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 References, Relationships
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Insufficient Input Validation

Common Weakness Enumeration

CWE VIEW: Weaknesses Addressed by the SEI CERT C Coding Standard

View Components

CWE-786: Access of Memory Location Before Start of Buffer

CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')

CWE-481: Assigning instead of Comparing

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

CWE-805: Buffer Access with Incorrect Length Value

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

CWE-369: Divide By Zero

CWE-415: Double Free

CWE-590: Free of Memory not on the Heap

CWE-686: Function Call With Incorrect Argument Type

CWE-685: Function Call With Incorrect Number of Arguments

CWE-628: Function Call with Incorrectly Specified Arguments

CWE-122: Heap-based Buffer Overflow

CWE-273: Improper Check for Dropped Privileges

CWE-664: Improper Control of a Resource Through its Lifetime

CWE-241: Improper Handling of Unexpected Data Type

CWE-67: Improper Handling of Windows Device Names

CWE-20: Improper Input Validation

CWE-667: Improper Locking