Description
The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
When changing platforms or protocol versions, in-memory organization of data may change in unintended ways. For example, some architectures may place local variables A and B right next to each other with A on top; some may place them next to each other with B on top; and others may add some padding to each. The padding size may vary to ensure that each variable is aligned to a proper word size. In protocol implementations, it is common to calculate an offset relative to another field to pick out a specific piece of data. Exceptional conditions, often involving new protocol versions, may add corner cases that change the data layout in an unusual way. The result can be that an implementation accesses an unintended field in the packet, treating data of one type as data of another type.
Potential Impact
Integrity, Confidentiality
Modify Memory, Read Memory
Demonstrative Examples
void example() {char a;char b;*(&a + 1) = 0;}Mitigations & Prevention
In flat address space situations, never allow computing memory addresses as offsets from another memory address.
Fully specify protocol layout unambiguously, providing a structured grammar (e.g., a compilable yacc grammar).
Testing: Test that the implementation properly handles each case in the protocol grammar.
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,
- Automated Dynamic Analysis Moderate — Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].
Related Weaknesses
Taxonomy Mappings
- CLASP: — Reliance on data layout
Frequently Asked Questions
What is CWE-188?
CWE-188 (Reliance on Data/Memory Layout) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
How can CWE-188 be exploited?
Attackers can exploit CWE-188 (Reliance on Data/Memory Layout) to modify memory, read memory. This weakness is typically introduced during the Implementation phase of software development.
How do I prevent CWE-188?
Key mitigations include: In flat address space situations, never allow computing memory addresses as offsets from another memory address.
What is the severity of CWE-188?
CWE-188 is classified as a Base-level weakness (Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.