CWE-188: Reliance on Data/Memory Layout
The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
Last updated
Overview
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.
Common consequences
What can happen when CWE-188 is exploited.
Modify Memory, Read Memory
Affects: Integrity, Confidentiality
Can result in unintended modifications or exposure of sensitive memory.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-188, grouped by where in the lifecycle they apply.
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.
How to detect it
Fuzzing
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.
Effectiveness: High
Automated Dynamic Analysis
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].
Effectiveness: Moderate
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
In this example function, the memory address of variable b is derived by adding 1 to the address of variable a. This derived address is then used to assign the value 0 to b.
Vulnerable example
void example() {Here, b may not be one byte past a. It may be one byte in front of a. Or, they may have three bytes between them because they are aligned on 32-bit boundaries.
Terminology & mappings
Mapped taxonomies
- CLASP: Reliance on data layout
Frequently asked questions
Common questions about CWE-188.
- What is CWE-188?
- The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
- How do you prevent CWE-188?
- In flat address space situations, never allow computing memory addresses as offsets from another memory address.
- How is CWE-188 detected?
- Fuzzing: 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.
- What are the consequences of CWE-188?
- Exploiting CWE-188 can lead to: Modify Memory, Read Memory.
References
- MITRE CWE definition (CWE-188) (opens in a new tab)
- CWE-188 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-188
Get alerted the moment a new CWE-188 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.