Reliance on Data/Memory Layout
Weakness ID: 188 (Weakness Base)Status: Draft
+ Description

Description Summary

The software makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Can result in unintended modifications or information leaks of data.

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

(Bad Code)
Example Language: C 
void example() {
char a;
char b;
*(&a + 1) = 0;
}

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 get aligned to 32-bit boundaries.

+ Potential Mitigations

Design and Implementation: In flat address space situations, never allow computing memory addresses as offsets from another memory address.

Phase: Architecture and Design

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.

+ Other Notes

When changing platforms or protocol versions, data may move 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. This ensured that each variable is aligned to a proper word size. In protocol implementations, it is common to 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 lead to the data layout changing in an unusual way. The result can be that an implementation accesses a particular part of a packet, treating data of one type as data of another type.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory137Representation Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class435Interaction Error
Research Concepts1000
ChildOfWeakness ClassWeakness Class758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base198Use of Incorrect Byte Ordering
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPReliance on data layout
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Relationships, Other Notes, Taxonomy Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common Consequences
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Reliance on Data Layout
Back to top