CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

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.

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.

Potential Impact

Other

Reduce Maintainability, Unexpected State, Quality Degradation

Demonstrative Examples

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

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.

The following function returns a stack address.

Bad

char* getName() {char name[STR_MAX];fillInName(name);return name;}

Detection Methods

Fuzzing High — 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,

Real-World CVE Examples

CVE ID	Description
CVE-2006-1902	Change in C compiler behavior causes resultant buffer overflows in programs that depend on behaviors that were undefined in the C standard.

Taxonomy Mappings

CERT C Secure Coding: ARR32-C — Ensure size arguments for variable length arrays are in a valid range
CERT C Secure Coding: ERR34-C — Detect errors when converting a string to a number
CERT C Secure Coding: EXP30-C — Do not depend on the order of evaluation for side effects
CERT C Secure Coding: EXP33-C — Do not read uninitialized memory
CERT C Secure Coding: FIO46-C — Do not access a closed file
CERT C Secure Coding: INT34-C — Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand
CERT C Secure Coding: INT36-C — Converting a pointer to integer or integer to pointer
CERT C Secure Coding: MEM30-C — Do not access freed memory
CERT C Secure Coding: MSC14-C — Do not introduce unnecessary platform dependencies
CERT C Secure Coding: MSC15-C — Do not depend on undefined behavior
CERT C Secure Coding: MSC37-C — Ensure that control never reaches the end of a non-void function

Frequently Asked Questions

What is CWE-758?

CWE-758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. 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.

How can CWE-758 be exploited?

Attackers can exploit CWE-758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior) to reduce maintainability, unexpected state, quality degradation. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-758?

Follow secure coding practices, conduct code reviews, and use automated security testing tools (SAST/DAST) to detect this weakness early in the development lifecycle.

What is the severity of CWE-758?

CWE-758 is classified as a Class-level weakness (High abstraction). It has been observed in 1 real-world CVEs.