CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-734: Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version) (3.0)  
ID

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

View ID: 734
Type: Graph
Status: Incomplete
+ Objective
CWE entries in this view (graph) are fully or partially eliminated by following the CERT C Secure Coding Standard, as published in 2008.
+ Audience
StakeholderDescription
Software DevelopersBy following the CERT C Secure Coding Standard, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Software CustomersIf a software developer claims to be following the CERT C Secure Coding standard, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
EducatorsEducators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.
+ Relationships
Show Details:
734 - Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 01 - Preprocessor (PRE) - (735)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 735 (CERT C Secure Coding (2008 Version) Section 01 - Preprocessor (PRE))
Weaknesses in this category are related to rules in the preprocessor section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassIncorrect Provision of Specified Functionality - (684)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 735 (CERT C Secure Coding (2008 Version) Section 01 - Preprocessor (PRE)) > 684 (Incorrect Provision of Specified Functionality)
The code does not function according to its published specifications, potentially leading to incorrect usage.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 02 - Declarations and Initialization (DCL) - (736)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 736 (CERT C Secure Coding (2008 Version) Section 02 - Declarations and Initialization (DCL))
Weaknesses in this category are related to rules in the declarations and initialization section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*VariantVariantUse of Hard-coded, Security-relevant Constants - (547)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 736 (CERT C Secure Coding (2008 Version) Section 02 - Declarations and Initialization (DCL)) > 547 (Use of Hard-coded, Security-relevant Constants)
The program uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.
*BaseBaseFunction Call with Incorrectly Specified Arguments - (628)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 736 (CERT C Secure Coding (2008 Version) Section 02 - Declarations and Initialization (DCL)) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
*VariantVariantFunction Call With Incorrect Argument Type - (686)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 736 (CERT C Secure Coding (2008 Version) Section 02 - Declarations and Initialization (DCL)) > 686 (Function Call With Incorrect Argument Type)
The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP) - (737)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP))
Weaknesses in this category are related to rules in the expressions section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*VariantVariantUse of sizeof() on a Pointer Type - (467)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP)) > 467 (Use of sizeof() on a Pointer Type)
The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated.
*BaseBaseIncorrect Pointer Scaling - (468)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP)) > 468 (Incorrect Pointer Scaling)
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
*BaseBaseNULL Pointer Dereference - (476)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP)) > 476 (NULL Pointer Dereference)
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
*BaseBaseFunction Call with Incorrectly Specified Arguments - (628)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 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.
*ClassClassIncorrect Type Conversion or Cast - (704)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP)) > 704 (Incorrect Type Conversion or Cast)
The software does not correctly convert an object, resource or structure from one type to a different type.
*VariantVariantOperator Precedence Logic Error - (783)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 737 (CERT C Secure Coding (2008 Version) Section 03 - Expressions (EXP)) > 783 (Operator Precedence Logic Error)
The program uses an expression in which operator precedence causes incorrect logic to be used.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 04 - Integers (INT) - (738)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT))
Weaknesses in this category are related to rules in the integers section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseImproper Validation of Array Index - (129)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 129 (Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow
*BaseBaseInteger Overflow or Wraparound - (190)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 190 (Integer Overflow or Wraparound)
The software 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.
*ClassClassInteger Coercion Error - (192)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 192 (Integer Coercion Error)
Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.
*BaseBaseNumeric Truncation Error - (197)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 197 (Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
*ClassClassImproper Input Validation - (20)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 20 (Improper Input Validation)
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
*BaseBaseDivide By Zero - (369)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 369 (Divide By Zero)
The product divides a value by zero.
*BaseBaseReturn of Pointer Value Outside of Expected Range - (466)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 466 (Return of Pointer Value Outside of Expected Range)
A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.
*BaseBaseAssignment of a Fixed Address to a Pointer - (587)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 587 (Assignment of a Fixed Address to a Pointer)
The software sets a pointer to a specific address other than NULL or 0.
*BaseBaseUnchecked Input for Loop Condition - (606)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 606 (Unchecked Input for Loop Condition)
The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service because of excessive looping.
*BaseBaseUse of Potentially Dangerous Function - (676)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 676 (Use of Potentially Dangerous Function)
The program invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
*ClassClassIncorrect Conversion between Numeric Types - (681)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 681 (Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
*ClassClassIncorrect Calculation - (682)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 738 (CERT C Secure Coding (2008 Version) Section 04 - Integers (INT)) > 682 (Incorrect Calculation)
The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP) - (739)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 739 (CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP))
Weaknesses in this category are related to rules in the floating point section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseDivide By Zero - (369)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 739 (CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP)) > 369 (Divide By Zero)
The product divides a value by zero.
*ClassClassIncorrect Conversion between Numeric Types - (681)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 739 (CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP)) > 681 (Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
*ClassClassIncorrect Calculation - (682)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 739 (CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP)) > 682 (Incorrect Calculation)
The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
*VariantVariantFunction Call With Incorrect Argument Type - (686)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 739 (CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP)) > 686 (Function Call With Incorrect Argument Type)
The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR) - (740)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR))
Weaknesses in this category are related to rules in the arrays section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Restriction of Operations within the Bounds of a Memory Buffer - (119)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The software 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.Memory Corruption
*BaseBaseImproper Validation of Array Index - (129)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 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
*VariantVariantUse of sizeof() on a Pointer Type - (467)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)) > 467 (Use of sizeof() on a Pointer Type)
The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated.
*BaseBaseUse of Pointer Subtraction to Determine Size - (469)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)) > 469 (Use of Pointer Subtraction to Determine Size)
The application 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.
*ClassClassImproper Initialization - (665)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)) > 665 (Improper Initialization)
The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
*BaseBaseBuffer Access with Incorrect Length Value - (805)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 740 (CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)) > 805 (Buffer Access with Incorrect Length Value)
The software 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.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR) - (741)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR))
Weaknesses in this category are related to rules in the characters and strings section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Restriction of Operations within the Bounds of a Memory Buffer - (119)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The software 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.Memory Corruption
*BaseBaseBuffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
The program 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.buffer overrunUnbounded Transfer
*BaseBaseIncorrect Calculation of Multi-Byte String Length - (135)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 135 (Incorrect Calculation of Multi-Byte String Length)
The software does not correctly calculate the length of strings that can contain wide or multi-byte characters.
*BaseBaseImproper Null Termination - (170)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 170 (Improper Null Termination)
The software does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
*BaseBaseOff-by-one Error - (193)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 193 (Off-by-one Error)
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.off-by-five
*BaseBaseAddition of Data Structure Sentinel - (464)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 464 (Addition of Data Structure Sentinel)
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
*VariantVariantFunction Call With Incorrect Argument Type - (686)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 686 (Function Call With Incorrect Argument Type)
The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
*ClassClassIncorrect Type Conversion or Cast - (704)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 704 (Incorrect Type Conversion or Cast)
The software does not correctly convert an object, resource or structure from one type to a different type.
*BaseBaseImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software 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
*BaseBaseArgument Injection or Modification - (88)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 741 (CERT C Secure Coding (2008 Version) Section 07 - Characters and Strings (STR)) > 88 (Argument Injection or Modification)
The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM) - (742)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM))
Weaknesses in this category are related to rules in the memory management section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Restriction of Operations within the Bounds of a Memory Buffer - (119)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The software 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.Memory Corruption
*BaseBaseWrap-around Error - (128)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 128 (Wrap-around Error)
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.
*BaseBaseIncorrect Calculation of Buffer Size - (131)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 131 (Incorrect Calculation of Buffer Size)
The software does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
*BaseBaseInteger Overflow or Wraparound - (190)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 190 (Integer Overflow or Wraparound)
The software 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.
*ClassClassImproper Input Validation - (20)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 20 (Improper Input Validation)
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
*BaseBaseSensitive Information Uncleared Before Release - (226)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 226 (Sensitive Information Uncleared Before Release)
The software does not fully clear previously used information in a data structure, file, or other resource, before making that resource available to a party in another control sphere.
*VariantVariantImproper Clearing of Heap Memory Before Release ('Heap Inspection') - (244)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 244 (Improper Clearing of Heap Memory Before Release ('Heap Inspection'))
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
*BaseBaseUnchecked Return Value - (252)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 252 (Unchecked Return Value)
The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*VariantVariantDouble Free - (415)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 415 (Double Free)
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free
*BaseBaseUse After Free - (416)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 416 (Use After Free)
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Dangling pointerUse-After-Free
*BaseBaseNULL Pointer Dereference - (476)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 476 (NULL Pointer Dereference)
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
*VariantVariantExposure of Core Dump File to an Unauthorized Control Sphere - (528)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere)
The product generates a core dump file in a directory that is accessible to actors outside of the intended control sphere.
*VariantVariantFree of Memory not on the Heap - (590)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 590 (Free of Memory not on the Heap)
The application calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
*VariantVariantSensitive Data Storage in Improperly Locked Memory - (591)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 591 (Sensitive Data Storage in Improperly Locked Memory)
The application stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.
*BaseBaseFunction Call with Incorrectly Specified Arguments - (628)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
*ClassClassImproper Initialization - (665)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 665 (Improper Initialization)
The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
*VariantVariantFunction Call With Incorrectly Specified Argument Value - (687)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 687 (Function Call With Incorrectly Specified Argument Value)
The software calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.
*ClassClassImproper Check for Unusual or Exceptional Conditions - (754)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 742 (CERT C Secure Coding (2008 Version) Section 08 - Memory Management (MEM)) > 754 (Improper Check for Unusual or Exceptional Conditions)
The software does not check or improperly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the software.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO) - (743)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO))
Weaknesses in this category are related to rules in the input/output section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Restriction of Operations within the Bounds of a Memory Buffer - (119)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The software 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.Memory Corruption
*BaseBaseUse of Externally-Controlled Format String - (134)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 134 (Use of Externally-Controlled Format String)
The software uses a function that accepts a format string as an argument, but the format string originates from an external source.
*ClassClassImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal
*BaseBaseImproper Handling of Unexpected Data Type - (241)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 241 (Improper Handling of Unexpected Data Type)
The software 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).
*VariantVariantIncorrect Default Permissions - (276)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 276 (Incorrect Default Permissions)
The software, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
*VariantVariantIncorrect Execution-Assigned Permissions - (279)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the software sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
*ClassClassConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
*BaseBaseTime-of-check Time-of-use (TOCTOU) Race Condition - (367)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
The software checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the software to perform invalid actions when the resource is in an unexpected state.TOCTTOUTOCCTOU
*VariantVariantPath Traversal: '/absolute/pathname/here' - (37)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 37 (Path Traversal: '/absolute/pathname/here')
A software system that accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*BaseBaseCreation of Temporary File in Directory with Incorrect Permissions - (379)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 379 (Creation of Temporary File in Directory with Incorrect Permissions)
The software creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
*VariantVariantPath Traversal: '\absolute\pathname\here' - (38)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 38 (Path Traversal: '\absolute\pathname\here')
A software system that accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*VariantVariantPath Traversal: 'C:dirname' - (39)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 39 (Path Traversal: 'C:dirname')
An attacker can inject a drive letter or Windows volume letter ('C:dirname') into a software system to potentially redirect access to an unintended location or arbitrary file.
*BaseBaseUnchecked Error Condition - (391)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 391 (Unchecked Error Condition)
Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
*BaseBaseExposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') - (403)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.File descriptor leak
*BaseBaseImproper Resource Shutdown or Release - (404)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 404 (Improper Resource Shutdown or Release)
The program does not release or incorrectly releases a resource before it is made available for re-use.
*BaseBaseImproper Resolution of Path Equivalence - (41)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 41 (Improper Resolution of Path Equivalence)
The system or application is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
*BaseBaseFiles or Directories Accessible to External Parties - (552)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 552 (Files or Directories Accessible to External Parties)
Files or directories are accessible in the environment that should not be.
*BaseBaseImproper Link Resolution Before File Access ('Link Following') - (59)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The software attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary file
*VariantVariantUNIX Hard Link - (62)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 62 (UNIX Hard Link)
The software, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.
*VariantVariantWindows Shortcut Following (.LNK) - (64)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 64 (Windows Shortcut Following (.LNK))
The software, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.Windows symbolic link followingsymlink
*VariantVariantWindows Hard Link - (65)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 65 (Windows Hard Link)
The software, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.
*VariantVariantImproper Handling of Windows Device Names - (67)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 67 (Improper Handling of Windows Device Names)
The software 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.
*ClassClassDuplicate Operations on Resource - (675)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 675 (Duplicate Operations on Resource)
The product performs the same operation on a resource two or more times, when the operation should only be applied once.
*BaseBaseUse of Potentially Dangerous Function - (676)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 676 (Use of Potentially Dangerous Function)
The program invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
*VariantVariantFunction Call With Incorrect Argument Type - (686)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 686 (Function Call With Incorrect Argument Type)
The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
*ClassClassIncorrect Permission Assignment for Critical Resource - (732)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 743 (CERT C Secure Coding (2008 Version) Section 09 - Input Output (FIO)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 10 - Environment (ENV) - (744)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV))
Weaknesses in this category are related to rules in the environment section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Restriction of Operations within the Bounds of a Memory Buffer - (119)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The software 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.Memory Corruption
*CompositeCompositeUntrusted Search Path - (426)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)) > 426 (Untrusted Search Path)
The application searches for critical resources using an externally-supplied search path that can point to resources that are not under the application's direct control.Untrusted Path
*BaseBaseDuplicate Key in Associative List (Alist) - (462)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)) > 462 (Duplicate Key in Associative List (Alist))
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
*ClassClassIncorrect Control Flow Scoping - (705)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
*BaseBaseImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software 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
*BaseBaseArgument Injection or Modification - (88)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 744 (CERT C Secure Coding (2008 Version) Section 10 - Environment (ENV)) > 88 (Argument Injection or Modification)
The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 11 - Signals (SIG) - (745)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 745 (CERT C Secure Coding (2008 Version) Section 11 - Signals (SIG))
Weaknesses in this category are related to rules in the signals section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*VariantVariantSignal Handler Use of a Non-reentrant Function - (479)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 745 (CERT C Secure Coding (2008 Version) Section 11 - Signals (SIG)) > 479 (Signal Handler Use of a Non-reentrant Function)
The program defines a signal handler that calls a non-reentrant function.
*BaseBaseImproper Synchronization - (662)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 745 (CERT C Secure Coding (2008 Version) Section 11 - Signals (SIG)) > 662 (Improper Synchronization)
The software attempts to use a shared resource in an exclusive manner, but does not prevent or incorrectly prevents use of the resource by another thread or process.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR) - (746)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 746 (CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR))
Weaknesses in this category are related to rules in the error handling section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Input Validation - (20)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 746 (CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)) > 20 (Improper Input Validation)
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
*BaseBaseUnchecked Error Condition - (391)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 746 (CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)) > 391 (Unchecked Error Condition)
Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
*BaseBaseMissing Standardized Error Handling Mechanism - (544)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 746 (CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)) > 544 (Missing Standardized Error Handling Mechanism)
The software does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
*BaseBaseUse of Potentially Dangerous Function - (676)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 746 (CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)) > 676 (Use of Potentially Dangerous Function)
The program invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
*ClassClassIncorrect Control Flow Scoping - (705)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 746 (CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC) - (747)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC))
Weaknesses in this category are related to rules in the miscellaneous section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseCompiler Removal of Code to Clear Buffers - (14)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 14 (Compiler Removal of Code to Clear Buffers)
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
*VariantVariantImproper Handling of Unicode Encoding - (176)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 176 (Improper Handling of Unicode Encoding)
The software does not properly handle when an input contains Unicode encoding.
*ClassClassImproper Input Validation - (20)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 20 (Improper Input Validation)
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
*ClassClassUse of Insufficiently Random Values - (330)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 330 (Use of Insufficiently Random Values)
The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
*BaseBaseUse of Incorrect Operator - (480)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 480 (Use of Incorrect Operator)
The programmer accidentally uses the wrong operator, which changes the application logic in security-relevant ways.
*VariantVariantComparing instead of Assigning - (482)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 482 (Comparing instead of Assigning)
The code uses an operator for comparison when the intention was to perform an assignment.
*VariantVariantDead Code - (561)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 561 (Dead Code)
The software contains dead code, which can never be executed.
*VariantVariantAssignment to Variable without Use - (563)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 563 (Assignment to Variable without Use)
The variable's value is assigned but never used, making it a dead store.Unused Variable
*VariantVariantExpression is Always False - (570)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 570 (Expression is Always False)
The software contains an expression that will always evaluate to false.
*VariantVariantExpression is Always True - (571)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 571 (Expression is Always True)
The software contains an expression that will always evaluate to true.
*ClassClassInsufficient Comparison - (697)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 697 (Insufficient Comparison)
The software compares two entities in a security-relevant context, but the comparison is insufficient, which may lead to resultant weaknesses.
*ClassClassIncorrect Type Conversion or Cast - (704)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 747 (CERT C Secure Coding (2008 Version) Section 49 - Miscellaneous (MSC)) > 704 (Incorrect Type Conversion or Cast)
The software does not correctly convert an object, resource or structure from one type to a different type.
+CategoryCategoryCERT C Secure Coding (2008 Version) Section 50 - POSIX (POS) - (748)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS))
Weaknesses in this category are related to rules in the POSIX section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseImproper Null Termination - (170)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 170 (Improper Null Termination)
The software does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
*BaseBaseUse of Inherently Dangerous Function - (242)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 242 (Use of Inherently Dangerous Function)
The program calls a function that can never be guaranteed to work safely.
*BaseBaseLeast Privilege Violation - (272)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
*BaseBaseImproper Check for Dropped Privileges - (273)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 273 (Improper Check for Dropped Privileges)
The software attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
*BaseBaseRace Condition Enabling Link Following - (363)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 363 (Race Condition Enabling Link Following)
The software 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 software to access the wrong file.
*BaseBaseRace Condition in Switch - (365)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 365 (Race Condition in Switch)
The code contains a switch statement in which the switched variable can be modified while the switch is still executing, resulting in unexpected behavior.
*BaseBaseRace Condition within a Thread - (366)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 366 (Race Condition within a Thread)
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
*BaseBaseReturn of Stack Variable Address - (562)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 562 (Return of Stack Variable Address)
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
*BaseBaseImproper Link Resolution Before File Access ('Link Following') - (59)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The software attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary file
*BaseBaseImproper Locking - (667)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 667 (Improper Locking)
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
*VariantVariantFunction Call With Incorrect Argument Type - (686)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 686 (Function Call With Incorrect Argument Type)
The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
*ClassClassIncorrect Behavior Order - (696)
734 (Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)) > 748 (CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)) > 696 (Incorrect Behavior Order)
The software performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
+ Notes

Maintenance

This view is no longer being actively maintained, since it statically represents the coding rules as they were in 2008.

Relationship

The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
+ References
[REF-597] "The CERT C Secure Coding Standard". Addison-Wesley Professional. 2008-10-14.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, References
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08Weaknesses Addressed by the CERT C Secure Coding Standard
+ View Metrics
CWEs in this viewTotal CWEs
Total106out of982
Weaknesses92out of 714
Categories14out of 237
Views0out of 31

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-464: Addition of Data Structure Sentinel

Weakness ID: 464
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
+ Extended Description
Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory461Data Structure Issues
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

Generally this error will cause the data structure to not work properly by truncating the data.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following example assigns some character values to a list of characters and prints them each individually, and then as a string. The third character value is intended to be an integer taken from user input and converted to an int.

(bad)
Example Language:
char *foo;
foo=malloc(sizeof(char)*5);
foo[0]='a';
foo[1]='a';
foo[2]=atoi(getc(stdin));
foo[3]='c';
foo[4]='\0'
printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3],foo[4]);
printf("%s\n",foo);

The first print statement will print each character separated by a space. However, if a non-integer is read from stdin by getc, then atoi will not make a conversion and return 0. When foo is printed as a string, the 0 at character foo[2] will act as a NULL terminator and foo[3] will never be printed.

+ Potential Mitigations

Phases: Implementation; Architecture and Design

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

Phase: Implementation

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

Phase: Architecture and Design

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

Phase: Operation

Use OS-level preventative functionality. This is not a complete solution.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAddition of data-structure sentinel
CERT C Secure CodingSTR03-CDo not inadvertently truncate a null-terminated byte string
CERT C Secure CodingSTR06-CDo not assume that strtok() leaves the parse string unchanged
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASP
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Addition of Data-structure Sentinel

CWE-88: Argument Injection or Modification

Weakness ID: 88
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic; Read Application Data; Modify Application Data

An attacker could include arguments that allow unintended commands or code to be executed, allow sensitive data to be read or modified or could cause other unintended behavior.
+ Demonstrative Examples

Example 1

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

(bad)
Example Language:
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);

}

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Note that if argv[1] is a very long argument, then this issue might also be subject to a buffer overflow (CWE-120).

+ Observed Examples
ReferenceDescription
Canonical Example
Web browser executes Telnet sessions using command line arguments that are specified by the web site, which could allow remote attackers to execute arbitrary commands.
Web browser allows remote attackers to execute commands by spawning Telnet with a log file option on the command line and writing arbitrary code into an executable file which is later executed.
Argument injection vulnerability in the mail function for PHP may allow attackers to bypass safe mode restrictions and modify command line arguments to the MTA (e.g. sendmail) possibly executing commands.
Help and Support center in windows does not properly validate HCP URLs, which allows remote attackers to execute arbitrary code via quotation marks in an "hcp://" URL.
Mail client does not sufficiently filter parameters of mailto: URLs when using them as arguments to mail executable, which allows remote attackers to execute arbitrary programs.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Mail client allows remote attackers to execute arbitrary code via a URI that uses a UNC network share pathname to provide an alternate configuration file.
SSH URI handler for web browser allows remote attackers to execute arbitrary code or conduct port forwarding via the a command line option.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Argument injection vulnerability in TellMe 1.2 and earlier allows remote attackers to modify command line arguments for the Whois program and obtain sensitive information via "--" style options in the q_Host parameter.
Beagle before 0.2.5 can produce certain insecure command lines to launch external helper applications while indexing, which allows attackers to execute arbitrary commands. NOTE: it is not immediately clear whether this issue involves argument injection, shell metacharacters, or other issues.
Argument injection vulnerability in Internet Explorer 6 for Windows XP SP2 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Mozilla Firefox 1.0.6 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Avant Browser 10.1 Build 17 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in the URI handler in Skype 2.0.*.104 and 2.5.*.0 through 2.5.*.78 for Windows allows remote authorized attackers to download arbitrary files via a URL that contains certain command-line switches.
Argument injection vulnerability in WinSCP 3.8.1 build 328 allows remote attackers to upload or download arbitrary files via encoded spaces and double-quote characters in a scp or sftp URI.
Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a "/" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka "Object Packager Dialogue Spoofing Vulnerability."
Argument injection vulnerability in HyperAccess 8.4 allows user-assisted remote attackers to execute arbitrary vbscript and commands via the /r option in a telnet:// URI, which is configured to use hawin32.exe.
Argument injection vulnerability in the telnet daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets certain client "-f" sequences as valid requests for the login program to skip authentication, which allows remote attackers to log into certain accounts, as demonstrated by the bin account.
Language interpreter's mail function accepts another argument that is concatenated to a string used in a dangerous popen() call. Since there is no neutralization of this argument, both OS Command Injection (CWE-78) and Argument Injection (CWE-88) are possible.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

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

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

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

Use 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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Affected Resources
  • System Process
+ 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.
+ Notes

Relationship

At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERArgument Injection or Modification
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
CERT C Secure CodingENV33-CImpreciseDo not call system()
CERT C Secure CodingSTR02-CSanitize data passed to complex subsystems
WASC30Mail Command Injection
+ References
[REF-859] Steven Christey. "Argument injection issues". <http://www.securityfocus.com/archive/1/archive/1/460089/100/100/threaded>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "The Argument Array", Page 567.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2009-10-29CWE Content TeamMITRE
updated Observed_Examples
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Observed_Examples, Relationships
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings

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

Weakness ID: 587
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software sets a pointer to a specific address other than NULL or 0.
+ Extended Description
Using a fixed address is not portable because that address will probably not be valid in all environments or platforms.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory465Pointer Issues
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

C#: (Undetermined Prevalence)

(Assembly classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

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

Technical Impact: DoS: Crash, Exit, or Restart

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

Technical Impact: Read Memory; Modify Memory

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

Example 1

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(bad)
Example Language:
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.

+ Potential Mitigations

Phase: Implementation

Never set a pointer to a fixed address.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingINT36-CImpreciseConverting a pointer to integer or integer to pointer
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions

CWE-563: Assignment to Variable without Use

Weakness ID: 563
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The variable's value is assigned but never used, making it a dead store.
+ Extended Description
After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass710Improper Adherence to Coding Standards
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory1006Bad Coding Practices
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.
+ Alternate Terms
Unused Variable
+ Demonstrative Examples

Example 1

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

(bad)
Example Language:
r = getName();
r = getNewBuffer(buf);
+ Potential Mitigations

Phase: Implementation

Remove unused variables from the code.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
CERT Perl Secure CodingMSC01-PLImpreciseDetect and remove unused variables
Software Fault PatternsSFP2Unused Entities
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Alternate_Terms, Name, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2014-06-23Unused Variable
2017-11-08Assignment to Variable without Use ('Unused Variable')

CWE-805: Buffer Access with Incorrect Length Value

Weakness ID: 805
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software 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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Applicable Platforms
The listings below show 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)

(Assembly classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

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: 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)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);
/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);

}

This function allocates a buffer of 64 bytes to store the hostname under the assumption that the maximum length value of hostname is 64 bytes, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then we 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)
Example Language:
int returnChunkSize(void *) {
/* if chunk info is valid, return the size of usable memory,
* else, return -1 to indicate an error
*/
...

}
int main() {
...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...

}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

Example 3

In the following example, the source character string is copied to the dest character string using the method strncpy.

(bad)
Example Language:
...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(source)-1);
...

However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below.

(good)
Example Language:
...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(dest)-1);
...

Example 4

In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file.

(bad)
Example Language:
#define LOG_INPUT_SIZE 40
// saves the file name to a log file

int outputFilenameToLog(char *filename, int length) {
int success;
// buffer with size set to maximum size for input to log file

char buf[LOG_INPUT_SIZE];
// copy filename to buffer

strncpy(buf, filename, length);
// save to log file

success = saveToLogFile(buf);

return success;

}

However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below.

(good)
Example Language:
...
// copy filename to buffer

strncpy(buf, filename, sizeof(buf)-1);
...
+ Observed Examples
ReferenceDescription
Chain: large length value causes buffer over-read (CWE-126)
Use of packet length field to make a calculation, then copy into a fixed-size buffer
Chain: retrieval of length value from an uninitialized memory location
Crafted length value in document reader leads to buffer overflow
SSL server overflow when the sum of multiple length fields exceeds a given value
Language interpreter API function doesn't validate length argument, leading to information exposure
+ 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.
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. 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

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 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 you are not in 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 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

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-59] [REF-57].

Effectiveness: Defense in Depth

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

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
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

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

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

Effectiveness: High

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.

Effectiveness: Moderate

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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingARR38-CImpreciseGuarantee that library functions do not form invalid pointers
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Why ACLs Are Important" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[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-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://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[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 DateSubmitterOrganizationSource
2010-01-15CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings

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

Weakness ID: 120
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The program 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 program attempts to put more data in a buffer than it can hold, or when a program 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 program 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.
+ Relationships

The table(s) below 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 "Development Concepts" (CWE-699)
+ Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass20Improper Input Validation
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

(Assembly classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

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: 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.
+ Alternate Terms
buffer overrun:Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow."
Unbounded Transfer
+ 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)
Example Language:
char last_name[20];
printf ("Enter your last name: ");
scanf ("%s", last_name);

The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total.

Example 2

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

(bad)
Example Language:
void manipulate_string(char* string){
char buf[24];
strcpy(buf, string);
...

}

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and blindly 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 excerpt below calls the gets() function in C, which is inherently unsafe.

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

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without restricting how much is copied. 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)
Example Language:
...
struct hostent *clienthp;
char hostname[MAX_LEN];

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

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

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

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

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

}

}
close(serversocket);

...

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

+ Observed Examples
ReferenceDescription
buffer overflow using command with long argument
buffer overflow in local program using long environment variable
buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
+ 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.
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. 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

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 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 you are not in 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 whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Architecture and Design

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

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

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

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

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

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

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
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

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

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

Effectiveness: High

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

Automated Dynamic Analysis

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

Manual Analysis

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

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

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

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Architecture or Design Review

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

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

Effectiveness: High

+ Functional Areas
  • Memory Management
+ Affected Resources
  • Memory
+ Memberships
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.
+ Notes

Relationship

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

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnbounded Transfer ('classic overflow')
7 Pernicious KingdomsBuffer Overflow
CLASPBuffer overflow
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A5CWE More SpecificBuffer Overflows
CERT C Secure CodingSTR31-CExactGuarantee that storage for strings has sufficient space for character data and the null terminator
WASC7Buffer Overflow
Software Fault PatternsSFP8Faulty Buffer Access
+ 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.microsoft.com/mspress/books/toc/5957.aspx>.
[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-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://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[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/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10CWE Content TeamMITRE
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24CWE Content TeamMITRE
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Relationships
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unbounded Transfer ('Classic Buffer Overflow')

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

Category ID: 735
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the preprocessor section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-684 PRE09-C Do not replace secure functions with less secure functions
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 01 - Preprocessor (PRE)

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

Category ID: 736
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the declarations and initialization section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-547 DCL06-C Use meaningful symbolic constants to represent literal values in program logic
  • CWE-628 DCL10-C Maintain the contract between the writer and caller of variadic functions
  • CWE-686 DCL35-C Do not invoke a function using a type that does not match the function definition
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 02 - Declarations and Initialization (DCL)

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

Category ID: 737
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the expressions section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-467 EXP01-C Do not take the size of a pointer to determine the size of the pointed-to type
  • CWE-468 EXP08-C Ensure pointer arithmetic is used correctly
  • CWE-476 EXP34-C Ensure a null pointer is not dereferenced
  • CWE-628 EXP37-C Call functions with the arguments intended by the API
  • CWE-704 EXP05-C Do not cast away a const qualification
  • CWE-783 EXP00-C Use parentheses for precedence of operation
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2009-07-27CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 03 - Expressions (EXP)

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

Category ID: 738
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the integers section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

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

CWE CATEGORY: CERT C Secure Coding (2008 Version) Section 05 - Floating Point (FLP)

Category ID: 739
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the floating point section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-369 FLP03-C Detect and handle floating point errors
  • CWE-681 FLP33-C Convert integers to floating point for floating point operations
  • CWE-681 FLP34-C Ensure that floating point conversions are within range of the new type
  • CWE-682 FLP32-C Prevent or detect domain and range errors in math functions
  • CWE-682 FLP33-C Convert integers to floating point for floating point operations
  • CWE-686 FLP31-C Do not call functions expecting real values with complex values
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, References, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 05 - Floating Point (FLP)

CWE CATEGORY: CERT C Secure Coding (2008 Version) Section 06 - Arrays (ARR)

Category ID: 740
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the arrays section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-119 ARR00-C Understand how arrays work
  • CWE-119 ARR33-C Guarantee that copies are made into storage of sufficient size
  • CWE-119 ARR34-C Ensure that array types in expressions are compatible
  • CWE-119 ARR35-C Do not allow loops to iterate beyond the end of an array
  • CWE-129 ARR00-C Understand how arrays work
  • CWE-129 ARR30-C Guarantee that array indices are within the valid range
  • CWE-129 ARR38-C Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element
  • CWE-467 ARR01-C Do not apply the sizeof operator to a pointer when taking the size of an array
  • CWE-469 ARR36-C Do not subtract or compare two pointers that do not refer to the same array
  • CWE-469 ARR37-C Do not add or subtract an integer to a pointer to a non-array object
  • CWE-665 ARR02-C Explicitly specify array bounds, even if implicitly defined by an initializer
  • CWE-805 ARR33-C Guarantee that copies are made into storage of sufficient size
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2011-09-13CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 06 - Arrays (ARR)

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

Category ID: 741
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the characters and strings section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-78 STR02-C Sanitize data passed to complex subsystems
  • CWE-88 STR02-C Sanitize data passed to complex subsystems
  • CWE-119 STR31-C Guarantee that storage for strings has sufficient space for character data and the null terminator
  • CWE-119 STR32-C Null-terminate byte strings as required
  • CWE-119 STR33-C Size wide character strings correctly
  • CWE-120 STR35-C Do not copy data from an unbounded source to a fixed-length array
  • CWE-135 STR33-C Size wide character strings correctly
  • CWE-170 STR03-C Do not inadvertently truncate a null-terminated byte string
  • CWE-170 STR32-C Null-terminate byte strings as required
  • CWE-193 STR31-C Guarantee that storage for strings has sufficient space for character data and the null terminator
  • CWE-464 STR03-C Do not inadvertently truncate a null-terminated byte string
  • CWE-464 STR06-C Do not assume that strtok() leaves the parse string unchanged
  • CWE-686 STR37-C Arguments to character handling functions must be representable as an unsigned char
  • CWE-704 STR34-C Cast characters to unsigned types before converting to larger integer sizes
  • CWE-704 STR37-C Arguments to character handling functions must be representable as an unsigned char
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 07 - Characters and Strings (STR)

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

Category ID: 742
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the memory management section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

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

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

Category ID: 743
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the input/output section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Membership
NatureTypeIDName
MemberOfViewView734Weaknesses Addressed by the CERT C Secure Coding Standard (2008 Version)
HasMemberClassClass22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
HasMemberVariantVariant37Path Traversal: '/absolute/pathname/here'
HasMemberVariantVariant38Path Traversal: '\absolute\pathname\here'
HasMemberVariantVariant39Path Traversal: 'C:dirname'
HasMemberBaseBase41Improper Resolution of Path Equivalence
HasMemberBaseBase59Improper Link Resolution Before File Access ('Link Following')
HasMemberVariantVariant62UNIX Hard Link
HasMemberVariantVariant64Windows Shortcut Following (.LNK)
HasMemberVariantVariant65Windows Hard Link
HasMemberVariantVariant67Improper Handling of Windows Device Names
HasMemberClassClass119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberBaseBase134Use of Externally-Controlled Format String
HasMemberBaseBase241Improper Handling of Unexpected Data Type
HasMemberVariantVariant276Incorrect Default Permissions
HasMemberVariantVariant279Incorrect Execution-Assigned Permissions
HasMemberClassClass362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
HasMemberBaseBase367Time-of-check Time-of-use (TOCTOU) Race Condition
HasMemberBaseBase379Creation of Temporary File in Directory with Incorrect Permissions
HasMemberBaseBase391Unchecked Error Condition
HasMemberBaseBase403Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
HasMemberBaseBase404Improper Resource Shutdown or Release
HasMemberBaseBase552Files or Directories Accessible to External Parties
HasMemberClassClass675Duplicate Operations on Resource
HasMemberBaseBase676Use of Potentially Dangerous Function
HasMemberVariantVariant686Function Call With Incorrect Argument Type
HasMemberClassClass732Incorrect Permission Assignment for Critical Resource
+ Notes

Relationship

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

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

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

Category ID: 744
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the environment section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-78 ENV03-C Sanitize the environment when invoking external programs
  • CWE-78 ENV04-C Do not call system() if you do not need a command processor
  • CWE-88 ENV03-C Sanitize the environment when invoking external programs
  • CWE-88 ENV04-C Do not call system() if you do not need a command processor
  • CWE-119 ENV01-C Do not make assumptions about the size of an environment variable
  • CWE-426 ENV03-C Sanitize the environment when invoking external programs
  • CWE-462 ENV02-C Beware of multiple environment variables with the same effective name
  • CWE-705 ENV32-C All atexit handlers must return normally
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 10 - Environment (ENV)

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

Category ID: 745
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the signals section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-432 SIG00-C Mask signals handled by noninterruptible signal handlers
  • CWE-479 SIG30-C Call only asynchronous-safe functions within signal handlers
  • CWE-479 SIG32-C Do not call longjmp() from inside a signal handler
  • CWE-479 SIG33-C Do not recursively invoke the raise() function
  • CWE-479 SIG34-C Do not call signal() from within interruptible signal handlers
  • CWE-662 SIG00-C Mask signals handled by noninterruptible signal handlers
  • CWE-662 SIG31-C Do not access or modify shared objects in signal handlers
  • CWE-828 SIG31-C Do not access or modify shared objects in signal handlers
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 11 - Signals (SIG)

CWE CATEGORY: CERT C Secure Coding (2008 Version) Section 12 - Error Handling (ERR)

Category ID: 746
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the error handling section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-20 ERR07-C Prefer functions that support error checking over equivalent functions that don't
  • CWE-391 ERR00-C Adopt and implement a consistent and comprehensive error-handling policy
  • CWE-544 ERR00-C Adopt and implement a consistent and comprehensive error-handling policy
  • CWE-676 ERR07-C Prefer functions that support error checking over equivalent functions that don't
  • CWE-705 ERR04-C Choose an appropriate termination strategy
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 12 - Error Handling (ERR)

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

Category ID: 747
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the miscellaneous section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-14 MSC06-C Be aware of compiler optimization when dealing with sensitive data
  • CWE-20 MSC08-C Library functions should validate their parameters
  • CWE-176 MSC10-C Character Encoding - UTF8 Related Issues
  • CWE-330 MSC30-C Do not use the rand() function for generating pseudorandom numbers
  • CWE-480 MSC02-C Avoid errors of omission
  • CWE-480 MSC03-C Avoid errors of addition
  • CWE-482 MSC02-C Avoid errors of omission
  • CWE-561 MSC07-C Detect and remove dead code
  • CWE-563 MSC00-C Compile cleanly at high warning levels
  • CWE-570 MSC00-C Compile cleanly at high warning levels
  • CWE-571 MSC00-C Compile cleanly at high warning levels
  • CWE-697 MSC31-C Ensure that return values are compared against the proper type
  • CWE-704 MSC31-C Ensure that return values are compared against the proper type
  • CWE-758 MSC14-C Do not introduce unnecessary platform dependencies
  • CWE-758 MSC15-C Do not depend on undefined behavior
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 49 - Miscellaneous (MSC)

CWE CATEGORY: CERT C Secure Coding (2008 Version) Section 50 - POSIX (POS)

Category ID: 748
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the POSIX section of the CERT C Secure Coding Standard, as published in 2008. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Notes

Relationship

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

  • CWE-59 POS01-C Check for the existence of links when dealing with files
  • CWE-170 POS30-C Use the readlink() function properly
  • CWE-242 POS33-C Do not use vfork()
  • CWE-272 POS02-C Follow the principle of least privilege
  • CWE-273 POS37-C Ensure that privilege relinquishment is successful
  • CWE-363 POS35-C Avoid race conditions while checking for the existence of a symbolic link
  • CWE-365 POS35-C Avoid race conditions while checking for the existence of a symbolic link
  • CWE-366 POS00-C Avoid race conditions with multiple threads
  • CWE-562 POS34-C Do not call putenv() with a pointer to an automatic variable as the argument
  • CWE-667 POS31-C Do not unlock or destroy another thread's mutex
  • CWE-686 POS34-C Do not call putenv() with a pointer to an automatic variable as the argument
  • CWE-696 POS36-C Observe correct revocation order while relinquishing privileges
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2017-11-08CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
Previous Entry Names
Change DatePrevious Entry Name
2017-11-08CERT C Secure Coding Section 50 - POSIX (POS)

CWE-482: Comparing instead of Assigning

Weakness ID: 482
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The code uses an operator for comparison when the intention was to perform an assignment.
+ Extended Description
In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase480Use of Incorrect Operator
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase480Use of Incorrect Operator
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
ImplementationThis bug primarily originates from a typo.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Availability
Integrity

Technical Impact: Unexpected State

The assignment will not take place, which should cause obvious program execution problems.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

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

}
int main() {

called(2);
return 0;

}

Example 2

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

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

void push(int i) {
p1++;
if(p1==(tos+SIZE)) {
// Print stack overflow error message and exit

}
*p1 == i;

}

int pop(void) {
if(p1==tos) {
// Print stack underflow error message and exit

}
p1--;
return *(p1+1);

}

int main(int argc, char *argv[]) {
// initialize tos and p1 to point to the top of stack
tos = stack;
p1 = stack;
// code to add and remove items from stack

...
return 0;

}

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

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

+ Potential Mitigations

Phase: Testing

Many IDEs and static analysis products will detect this problem.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPComparing instead of assigning
Software Fault PatternsSFP2Unused Entities
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASP
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Modes_of_Introduction
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings

CWE-14: Compiler Removal of Code to Clear Buffers

Weakness ID: 14
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
+ Extended Description

This compiler optimization error occurs when:

1. Secret data are stored in memory.
2. The secret data are scrubbed from memory by overwriting its contents.
3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
Build and Compilation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Memory; Bypass Protection Mechanism

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

Example 1

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

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

if (ConnectToMainframe(MFAddr, pwd)) {
// Interaction with mainframe

}

}
memset(pwd, 0, sizeof(pwd));

}

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

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

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

+ Potential Mitigations

Phase: Implementation

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

Phase: Build and Compilation

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

Phase: Architecture and Design

Where possible, encrypt sensitive data that are used by a software system.
+ Detection Methods

Black Box

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

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.
+ Affected Resources
  • Memory
+ Memberships
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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInsecure Compiler Optimization
PLOVERSensitive memory uncleared by compiler optimization
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMSC06-CBe aware of compiler optimization when dealing with sensitive data
Software Fault PatternsSFP23Exposed Data
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-124] Michael Howard. "When scrubbing secrets in memory doesn't work". BugTraq. 2002-11-05. <http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html>.
[REF-125] Michael Howard. "Some Bad News and Some Good News". Microsoft. 2002-10-21. <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure10102002.asp>.
[REF-126] Joseph Wagner. "GNU GCC: Optimizer Removes Code Necessary for Security". Bugtraq. 2002-11-16. <http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-11/0257.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes, Potential_Mitigations, Relationships, Taxonomy_Mappings, Time_of_Introduction
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insecure Compiler Optimization

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

Weakness ID: 362
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
+ Extended Description

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

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

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

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Sometimes Prevalent)

C++: (Sometimes Prevalent)

Java: (Sometimes Prevalent)

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Concurrent Systems Operating on Shared Resources: (Often Prevalent)

+ Common Consequences

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

ScopeImpactLikelihood
Availability

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

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

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

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

Technical Impact: Read Files or Directories; Read Application Data

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

Example 1

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

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

if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");

}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");

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

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

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

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

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

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

Example 2

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

(bad)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */


pthread_mutex_unlock(mutex);

}

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

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

(good)
 
int f(pthread_mutex_t *mutex) {
int result;

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

/* access shared resource */


return pthread_mutex_unlock(mutex);

}
+ Observed Examples
ReferenceDescription
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Black Box

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

White Box

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

Automated Dynamic Analysis

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

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

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

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

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

Effectiveness: High

Manual Static Analysis - Source Code

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

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

Effectiveness: High

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Architecture or Design Review

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

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

Effectiveness: High

+ Memberships
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.
+ Notes

Maintenance

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

Research Gap

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

Research Gap

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

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
CERT Java Secure CodingVNA03-JDo not assume that a group of calls to independently atomic methods is atomic
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <http://www.ddj.com/cpp/184403766>.
[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.
[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.
[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.
[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <http://www.blakewatts.com/namedpipepaper.html>.
[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.
[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <http://blogs.sans.org/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Contributions
Contribution DateContributorOrganizationSource
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

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

Weakness ID: 379
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
+ Extended Description
On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase377Insecure Temporary File
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory376Temporary File Issues
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Since the file is visible and the application which is using the temp file could be known, the attacker has gained information about what the user is doing at that time.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

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

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

perror("Could not open new temporary file\n");
return (-1);

}
// write data to tmp file

...
// remove tmp file
rmtmp();

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

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

}
catch (IOException e) {
}

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

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

+ Potential Mitigations

Phase: Requirements

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

Phase: Implementation

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

Phase: Implementation

Avoid using vulnerable temp file functions.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPGuessed or visible temporary file
CERT C Secure CodingFIO15-CEnsure that file operations are performed in a secure directory
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Temporary Files", Page 538.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASP
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Guessed or Visible Temporary File
2009-05-27Creation of Temporary File in Directory with Insecure Permissions

CWE-561: Dead Code

Weakness ID: 561
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software contains dead code, which can never be executed.
+ Extended Description
Dead code is source code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass710Improper Adherence to Coding Standards
CanFollowVariantVariant570Expression is Always False
CanFollowVariantVariant571Expression is Always True
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory1006Bad Coding Practices
CanFollowVariantVariant570Expression is Always False
CanFollowVariantVariant571Expression is Always True
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

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

Example 1

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

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

}

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

}

Example 2

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

(bad)
Example Language: Java 
public class DoubleDead {
private void doTweedledee() {
doTweedledumb();

}
private void doTweedledumb() {
doTweedledee();

}
public static void main(String[] args) {
System.out.println("running DoubleDead");

}

}

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

Example 3

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

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

public String getGlue() {
return "glue";

}

}
+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing man-in-the-middle attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle')).
+ Potential Mitigations

Phase: Implementation

Remove dead code before deploying the application.

Phase: Testing

Use a static analysis tool to spot dead code.
+ Detection Methods

Architecture or Design Review

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

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

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Automated Monitored Execution

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

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

Effectiveness: High

+ Memberships
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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC07-CDetect and remove dead code
CERT Perl Secure CodingMSC00-PLExactDetect and remove dead code
Software Fault PatternsSFP2Unused Entities
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings

CWE-369: Divide By Zero

Weakness ID: 369
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product divides a value by zero.
+ Extended Description
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass682Incorrect Calculation
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass682Incorrect Calculation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass682Incorrect Calculation
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

A Divide by Zero results in a crash.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.

(bad)
Example Language: Java 
public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests;

}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.

(good)
 
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) {
System.out.println("Division by zero attempted!");
throw ArithmeticException;

}
return totalTime / numRequests;

}

Example 2

The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(bad)
Example Language:
double divide(double x, double y){
return x/y;

}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.

(good)
 
const int DivideByZero = 10;
double divide(double x, double y){
if ( 0 == y ){
throw DivideByZero;

}
return x/y;

}
...
try{
divide(10, 0);

}
catch( int i ){
if(i==DivideByZero) {
cerr<<"Divide by zero error";

}

}

Example 2 References:

[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <http://www.cprogramming.com/tutorial/exceptions.html>.

Example 3

The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(bad)
Example Language: C# 
int Division(int x, int y){
return (x / y);

}

The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero.

(good)
 
int SafeDivision(int x, int y){
try{
return (x / y);

}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero attempted!");
return 0;

}

}

Example 3 References:

[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.
+ Observed Examples
ReferenceDescription
Invalid size value leads to divide by zero.
"Empty" content triggers divide by zero.
Height value of 0 triggers divide by zero.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFLP03-CDetect and handle floating point errors
CERT C Secure CodingINT33-CExactEnsure that division and remainder operations do not result in divide-by-zero errors
CERT Java Secure CodingNUM02-JEnsure that division and modulo operations do not result in divide-by-zero errors
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings

CWE-415: Double Free

Weakness ID: 415
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
+ Extended Description
When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory399Resource Management Errors
PeerOfBaseBase416Use After Free
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.
+ Alternate Terms
Double-free
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code shows a simple example of a double free vulnerability.

(bad)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);

}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 2

While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on.

(bad)
Example Language:
#include <stdio.h>
#include <unistd.h>
#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)

int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf1R2;
buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);
free(buf1R1);
free(buf2R1);
buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);
free(buf2R1);
free(buf1R2);

}
+ Observed Examples
ReferenceDescription
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition that leads to a double free (CWE-415).
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free from invalid ASN.1 encoding.
Double free from malformed GIF.
Double free from malformed GIF.
Double free from malformed compressed data.
+ Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Phase: Implementation

Use a static analysis tool to find double free instances.
+ 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.
+ Notes

Maintenance

It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.

Relationship

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDFREE - Double-Free Vulnerability
7 Pernicious KingdomsDouble Free
CLASPDoubly freeing memory
CERT C Secure CodingMEM00-CAllocate and free memory in the same module, at the same level of abstraction
CERT C Secure CodingMEM01-CStore a new value in pointers immediately after free()
CERT C Secure CodingMEM30-CCWE More SpecificDo not access freed memory
CERT C Secure CodingMEM31-CFree dynamically allocated memory exactly once
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Double Frees", Page 379.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, White_Box_Definitions

CWE-462: Duplicate Key in Associative List (Alist)

Weakness ID: 462
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
+ Extended Description
A duplicate key entry -- if the alist is designed properly -- could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory461Data Structure Issues
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

Java: (Undetermined Prevalence)

C#: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following code adds data to a list and then attempts to sort the data.

(bad)
Example Language: Python 
alist = []
while (foo()): #now assume there is a string data with a key basename
queue.append(basename,data)
queue.sort()

Since basename is not necessarily unique, this may not sort how one would like it to be.

+ Potential Mitigations

Phase: Architecture and Design

Use a hash table instead of an alist.

Phase: Architecture and Design

Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDuplicate key in associative list (alist)
CERT C Secure CodingENV02-CBeware of multiple environment variables with the same effective name
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASP
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings

CWE-675: Duplicate Operations on Resource

Weakness ID: 675
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product performs the same operation on a resource two or more times, when the operation should only be applied once.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass573Improper Following of Specification by Caller
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Other

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

Relationship

This weakness is probably closely associated with other issues related to doubling, such as CWE-462 (duplicate key in alist) or CWE-102 (Struts duplicate validation forms). It's usually a case of an API contract violation (CWE-227).
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Relevant_Properties, Taxonomy_Mappings

CWE-528: Exposure of Core Dump File to an Unauthorized Control Sphere

Weakness ID: 528
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product generates a core dump file in a directory that is accessible to actors outside of the intended control sphere.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
OperationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

+ Potential Mitigations

Phase: System Configuration

Protect the core dump files from unauthorized access.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMEM06-CEnsure that sensitive data is not written out to disk
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings, Time_of_Introduction
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Core Dump Files

CWE-403: Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')

Weakness ID: 403
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.
+ Extended Description
When a new process is forked or executed, the child process inherits any open file descriptors. When the child process has fewer privileges than the parent process, this might introduce a vulnerability if the child process can access the file descriptor but does not have the privileges to access the associated file.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

Operating Systems

(Unix classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Alternate Terms
File descriptor leak:While this issue is frequently called a file descriptor leak, the "leak" term is often used in two different ways - exposure of a resource, or consumption of a resource. Use of this term could cause confusion.
+ Observed Examples
ReferenceDescription
Server leaks a privileged file descriptor, allowing the server to be hijacked.
File descriptor leak allows read of restricted files.
Access to restricted resource using modified file descriptor for stderr.
Open file descriptor used as alternate channel in complex race condition.
Program does not fully drop privileges after creating a file descriptor, which allows access to the descriptor via a separate vulnerability.
User bypasses restrictions by obtaining a file descriptor then calling setuid program, which does not close the descriptor.
Terminal manager does not properly close file descriptors, allowing attackers to access terminals of other users.
Module opens a file for reading twice, allowing attackers to read files.
+ Affected Resources
  • System Process
  • File or Directory
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUNIX file descriptor leak
CERT C Secure CodingFIO42-CEnsure files are properly closed when they are no longer needed
Software Fault PatternsSFP23Exposed Data
+ References
[REF-392] Paul Roberts. "File descriptors and setuid applications". 2007-02-05. <https://blogs.oracle.com/paulr/entry/file_descriptors_and_setuid_applications>.
[REF-393] Apple. "Introduction to Secure Coding Guide". Elevating Privileges Safely. <https://developer.apple.com/library/mac/#documentation/security/conceptual/SecureCodingGuide/Articles/AccessControl.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Affected_Resources, Observed_Examples, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Observed_Examples, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29UNIX File Descriptor Leak
2013-02-21Exposure of File Descriptor to Unintended Control Sphere

CWE-570: Expression is Always False

Weakness ID: 570
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software contains an expression that will always evaluate to false.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass710Improper Adherence to Coding Standards
CanPrecedeVariantVariant561Dead Code
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory569Expression Issues
CanPrecedeVariantVariant561Dead Code
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

In the following Java example the updateUserAccountOrder() method used within an e-business product ordering/inventory application will validate the product number that was ordered and the user account number. If they are valid, the method will update the product inventory, the user account, and the user order appropriately.

(bad)
Example Language: Java 

public void updateUserAccountOrder(String productNumber, String accountNumber) {
boolean isValidProduct = false;
boolean isValidAccount = false;

if (validProductNumber(productNumber)) {
isValidProduct = true;
updateInventory(productNumber);

}
else {
return;

}

if (validAccountNumber(accountNumber)) {
isValidProduct = true;
updateAccount(accountNumber, productNumber);

}

if (isValidProduct && isValidAccount) {
updateAccountOrder(accountNumber, productNumber);

}

}

However, the method never sets the isValidAccount variable after initializing it to false so the isValidProduct is mistakenly used twice. The result is that the expression "isValidProduct && isValidAccount" will always evaluate to false, so the updateAccountOrder() method will never be invoked. This will create serious problems with the product ordering application since the user account and inventory databases will be updated but the order will not be updated.

This can be easily corrected by updating the appropriate variable.

(good)
 
...
if (validAccountNumber(accountNumber)) {
isValidAccount = true;
updateAccount(accountNumber, productNumber);

}
...

Example 2

In the following example, the hasReadWriteAccess method uses bit masks and bit operators to determine if a user has read and write privileges for a particular process. The variable mask is defined as a bit mask from the BIT_READ and BIT_WRITE constants that have been defined. The variable mask is used within the predicate of the hasReadWriteAccess method to determine if the userMask input parameter has the read and write bits set.

(bad)
Example Language:
#define BIT_READ 0x0001 // 00000001
#define BIT_WRITE 0x0010 // 00010000

unsigned int mask = BIT_READ & BIT_WRITE; /* intended to use "|" */

// using "&", mask = 00000000
// using "|", mask = 00010001

// determine if user has read and write access
int hasReadWriteAccess(unsigned int userMask) {
// if the userMask has read and write bits set
// then return 1 (true)
if (userMask & mask) {
return 1;

}

// otherwise return 0 (false)
return 0;

}

However the bit operator used to initialize the mask variable is the AND operator rather than the intended OR operator (CWE-480), this resulted in the variable mask being set to 0. As a result, the if statement will always evaluate to false and never get executed.

The use of bit masks, bit operators and bitwise operations on variables can be difficult. If possible, try to use frameworks or libraries that provide appropriate functionality and abstract the implementation.

Example 3

In the following example, the updateInventory method used within an e-business inventory application will update the inventory for a particular product. This method includes an if statement with an expression that will always evaluate to false. This is a common practice in C/C++ to introduce debugging statements quickly by simply changing the expression to evaluate to true and then removing those debugging statements by changing expression to evaluate to false. This is also a common practice for disabling features no longer needed.

(bad)
Example Language:
int updateInventory(char* productNumber, int numberOfItems) {
int initCount = getProductCount(productNumber);

int updatedCount = initCount + numberOfItems;

int updated = updateProductCount(updatedCount);

// if statement for debugging purposes only
if (1 == 0) {

char productName[128];
productName = getProductName(productNumber);

printf("product %s initially has %d items in inventory \n", productName, initCount);
printf("adding %d items to inventory for %s \n", numberOfItems, productName);

if (updated == 0) {
printf("Inventory updated for product %s to %d items \n", productName, updatedCount);

}

else {
printf("Inventory not updated for product: %s \n", productName);

}

}

return updated;

}

Using this practice for introducing debugging statements or disabling features creates dead code that can cause problems during code maintenance and potentially introduce vulnerabilities. To avoid using expressions that evaluate to false for debugging purposes a logging API or debugging API should be used for the output of debugging messages.

+ Potential Mitigations

Phase: Testing

Use Static Analysis tools to spot such conditions.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Other_Notes, Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Relationships, Taxonomy_Mappings

CWE-571: Expression is Always True

Weakness ID: 571
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software contains an expression that will always evaluate to true.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass710Improper Adherence to Coding Standards
CanPrecedeVariantVariant561Dead Code
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory569Expression Issues
CanPrecedeVariantVariant561Dead Code
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

In the following Java example the updateInventory() method used within an e-business product ordering/inventory application will check if the input product number is in the store or in the warehouse. If the product is found, the method will update the store or warehouse database as well as the aggregate product database. If the product is not found, the method intends to do some special processing without updating any database.

(bad)
Example Language: Java 

public void updateInventory(String productNumber) {
boolean isProductAvailable = false;
boolean isDelayed = false;

if (productInStore(productNumber)) {
isProductAvailable = true;
updateInStoreDatabase(productNumber);

}
else if (productInWarehouse(productNumber)) {
isProductAvailable = true;
updateInWarehouseDatabase(productNumber);

}
else {
isProductAvailable = true;

}

if ( isProductAvailable ) {
updateProductDatabase(productNumber);

}
else if ( isDelayed ) {
/* Warn customer about delay before order processing */
...

}

}

However, the method never sets the isDelayed variable and instead will always update the isProductAvailable variable to true. The result is that the predicate testing the isProductAvailable boolean will always evaluate to true and therefore always update the product database. Further, since the isDelayed variable is initialized to false and never changed, the expression always evaluates to false and the customer will never be warned of a delay on their product.

+ Potential Mitigations

Phase: Testing

Use Static Analysis tools to spot such conditions.
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings

CWE-552: Files or Directories Accessible to External Parties

Weakness ID: 552
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
Files or directories are accessible in the environment that should not be.
+ Relationships

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

+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass668Exposure of Resource to Wrong Sphere
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
ImplementationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
OperationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Files or Directories; Modify Files or Directories

+ Affected Resources
  • File or Directory
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
CERT C Secure CodingFIO15-CEnsure that file operations are performed in a secure directory
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-09-09Veracode
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Modes_of_Introduction, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Errant Files or Directories Accessible

CWE-590: Free of Memory not on the Heap

Weakness ID: 590
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The application calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
+ Extended Description
When free() is called on an invalid pointer, the program's memory management data structures may become corrupted. This corruption can cause the program to crash or, in some circumstances, an attacker may be able to cause free() to operate on controllable memory locations to modify critical program variables or execute code.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfVariantVariant762Mismatched Memory Management Routines
CanPrecedeBaseBase123Write-what-where Condition
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory399Resource Management Errors
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands; Modify Memory

There is the potential for arbitrary code execution with privileges of the vulnerable program via a "write, what where" primitive. If pointers to memory which hold user information are freed, a malicious user will be able to write 4 bytes anywhere in memory.
+ Demonstrative Examples

Example 1

In this example, an array of record_t structs, bar, is allocated automatically on the stack as a local variable and the programmer attempts to call free() on the array. The consequences will vary based on the implementation of free(), but it will not succeed in deallocating the memory.

(bad)
Example Language:
void foo(){
record_t bar[MAX_SIZE];
/* do something interesting with bar */

...
free(bar);

}

This example shows the array allocated globally, as part of the data segment of memory and the programmer attempts to call free() on the array.

(bad)
Example Language:
record_t bar[MAX_SIZE]; //Global var
void foo(){
/* do something interesting with bar */
...
free(bar);

}

Instead, if the programmer wanted to dynamically manage the memory, malloc() or calloc() should have been used.

(good)
 
void foo(){
record_t *bar = (record_t*)malloc(MAX_SIZE*sizeof(record_t));
/* do something interesting with bar */

...
free(bar);

}

Additionally, you can pass global variables to free() when they are pointers to dynamically allocated memory.

(good)
 
record_t *bar; //Global var
void foo(){
bar = (record_t*)malloc(MAX_SIZE*sizeof(record_t));
/* do something interesting with bar */

...
free(bar);

}
+ Potential Mitigations

Phase: Implementation

Only free pointers that you have called malloc on previously. This is the recommended solution. Keep track of which pointers point at the beginning of valid chunks and free them only once.

Phase: Implementation

Before freeing a pointer, the programmer should make sure that the pointer was previously allocated on the heap and that the memory belongs to the programmer. Freeing an unallocated pointer will cause undefined behavior in the program.

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. For example, glibc in Linux provides protection against free of invalid pointers.

Phase: Architecture and Design

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Use a tool that dynamically detects memory management problems, such as valgrind.
+ 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.
+ Notes

Maintenance

In C++, if the new operator was used to allocate the memory, it may be allocated with the malloc(), calloc() or realloc() family of functions in the implementation. Someone aware of this behavior might choose to map this problem to CWE-590 or to its parent, CWE-762, depending on their perspective.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMEM34-CExactOnly free memory allocated dynamically
CERT C Secure CodingWIN30-CImpreciseProperly pair allocation and deallocation functions
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-480] "Valgrind". <http://valgrind.org/>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Name, Other_Notes, Potential_Mitigations, References, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improperly Freeing Heap Memory
2009-05-27Free of Invalid Pointer Not on the Heap
2009-10-29Free of Memory not on the Heap

CWE-686: Function Call With Incorrect Argument Type

Weakness ID: 686
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
+ Extended Description
This weakness is most likely to occur in loosely typed languages, or in strongly typed languages in which the types of variable arguments cannot be enforced at compilation time, or where there is implicit casting.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
+ 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 software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Potential Mitigations

Phase: Testing

Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the software. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingEXP37-CCWE More SpecificCall functions with the correct number and type of arguments
CERT C Secure CodingFIO47-CImpreciseUse valid format strings
CERT C Secure CodingPOS34-CDo not call putenv() with a pointer to an automatic variable as the argument
CERT C Secure CodingSTR37-CArguments to character handling functions must be representable as an unsigned char
Software Fault Pa