Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

Incomplete Class
Structure: Simple
Description

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

Extended Description

This can lead to resultant weaknesses when the required properties change, such as when the product is ported to a different platform or if an interaction error (CWE-435) occurs.

Common Consequences 1
Scope: Other

Impact: Other

Detection Methods 1
FuzzingHigh
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
Demonstrative Examples 2

ID : DX-192

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.

Code Example:

Bad
C
c

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

ID : DX-203

The following function returns a stack address.

Code Example:

Bad
C
c
Observed Examples 1
CVE-2006-1902Change in C compiler behavior causes resultant buffer overflows in programs that depend on behaviors that were undefined in the C standard.
Taxonomy Mapping
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding