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
Scope
Effect
Integrity
Confidentiality
Can result in unintended modifications or information leaks of
data.
Likelihood of Exploit
Low
Demonstrative Examples
Example 1
(Bad Code)
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
Phase
Description
Design and Implementation: In flat address space situations, never
allow computing memory addresses as offsets from another memory
address.
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.
Description
