Difference between revisions of "Reliance on data layout"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 +
 +
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 +
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
Line 13: Line 16:
 
Assumptions about protocol data or data stored in memory can be invalid, resulting in using data in ways that were unintended.
 
Assumptions about protocol data or data stored in memory can be invalid, resulting in using data in ways that were unintended.
  
'''Consequences ==
+
'''Consequences'''
  
 
Access control (including confidentiality and integrity): Can result in unintended modifications or information leaks of data.
 
Access control (including confidentiality and integrity): Can result in unintended modifications or information leaks of data.
  
==Exposure period ==
+
'''Exposure period'''
  
 
Design: This problem can arise when a protocol leaves room for interpretation and is implemented by multiple parties that need to interoperate.  
 
Design: This problem can arise when a protocol leaves room for interpretation and is implemented by multiple parties that need to interoperate.  
Line 23: Line 26:
 
Implementation: This problem can arise by not understanding the subtleties either of writing portable code or of changes between protocol versions.
 
Implementation: This problem can arise by not understanding the subtleties either of writing portable code or of changes between protocol versions.
  
==Platform ==
+
'''Platform'''
  
 
Protocol errors of this nature can happen on any platform. Invalid memory layout assumptions are possible in languages and environments with a single, flat memory space, such as C/C++ and Assembly.
 
Protocol errors of this nature can happen on any platform. Invalid memory layout assumptions are possible in languages and environments with a single, flat memory space, such as C/C++ and Assembly.
  
==Required resources ==
+
'''Required resources'''
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
Medium to High
 
Medium to High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Low
 
Low
  
 +
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.
  
 
==Risk Factors==
 
==Risk Factors==
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
+
TBD
* Discuss the technical impact of a successful exploit of this vulnerability
+
* Consider the likely [business impacts] of a successful attack
+
 
+
  
 
==Examples==
 
==Examples==
  
===Short example name===
+
In C:
: A short example description, small picture, or sample code with [http://www.site.com links]
+
  
===Short example name===
+
<pre>void example() {
: A short example description, small picture, or sample code with [http://www.site.com links]
+
  char a;
 +
  char b;
 +
  *(&a + 1) = 0;
 +
}</pre>
  
 +
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.
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
Line 70: Line 75:
 
==Related [[Controls]]==
 
==Related [[Controls]]==
  
* [[Control 1]]
+
* Design and Implementation: In flat address space situations, never allow computing memory addresses as offsets from another memory address.
* [[Control 2]]
+
* 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.
  
  
Line 81: Line 87:
  
 
==References==
 
==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 
  
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
+
TBD
* http://www.link1.com
+
* [http://www.link2.com Title for the link2]
+
  
 
[[Category:FIXME|add links
 
[[Category:FIXME|add links
Line 117: Line 120:
  
 
[[Category:OWASP ASDR Project]]
 
[[Category:OWASP ASDR Project]]
 
 
==Overview==
 
 
 
==Avoidance and mitigation ==
 
 
* Design and Implementation: In flat address space situations, never allow computing memory addresses as offsets from another memory address.
 
 
* 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.
 
 
==Discussion ==
 
 
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.
 
 
==Examples ==
 
 
In C:
 
 
<pre>void example() {
 
  char a;
 
  char b;
 
  *(&a + 1) = 0;
 
}</pre>
 
 
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.
 
 
==Related problems ==
 
 
Not available.
 
 
 
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 
 
[[Category:Environmental Vulnerability]]
 
[[Category:Environmental Vulnerability]]
 
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]

Revision as of 13:23, 30 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

Last revision (mm/dd/yy): 09/30/2008

Vulnerabilities Table of Contents

ASDR Table of Contents

Contents


Description

Assumptions about protocol data or data stored in memory can be invalid, resulting in using data in ways that were unintended.

Consequences

Access control (including confidentiality and integrity): Can result in unintended modifications or information leaks of data.

Exposure period

Design: This problem can arise when a protocol leaves room for interpretation and is implemented by multiple parties that need to interoperate.

Implementation: This problem can arise by not understanding the subtleties either of writing portable code or of changes between protocol versions.

Platform

Protocol errors of this nature can happen on any platform. Invalid memory layout assumptions are possible in languages and environments with a single, flat memory space, such as C/C++ and Assembly.

Required resources

Any

Severity

Medium to High

Likelihood of exploit

Low

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.

Risk Factors

TBD

Examples

In 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.

Related Attacks


Related Vulnerabilities

Related Controls

  • Design and Implementation: In flat address space situations, never allow computing memory addresses as offsets from another memory address.
  • 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.


Related Technical Impacts


References

TBD