Difference between revisions of "Unintentional pointer scaling"

From OWASP
Jump to: navigation, search
(Examples)
(Description)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
 
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Consequences ==
+
==Description==
 +
In C and C++, one may accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
 +
 
 +
'''Consequences'''
  
 
Often results in buffer overflow conditions.
 
Often results in buffer overflow conditions.
  
==Exposure period ==
+
'''Exposure period'''
  
* Design: Could choose a language with abstractions for memory access.
+
* Design: Could choose a language with abstractions for memory access.
 +
* Implementation: This problem generally is due to a programmer error.
  
* Implementation: This problem generally is due to a programmer error.
+
'''Platform'''
 
+
==Platform ==
+
  
 
C and C++.
 
C and C++.
  
==Required resources ==
+
'''Required resources'''
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Medium
 
Medium
  
==Avoidance and mitigation ==
+
Programmers will often try to index from a pointer by adding a number of bytes, even though this is wrong, since C and C++ implicitly scale the operand by the size of the data type.
  
* Design: Use a platform with high-level memory abstractions.
+
==Risk Factors==
  
* Implementation: Always use array indexing instead of direct pointer manipulation.
+
TBD
  
* Other: Use technologies for preventing buffer overflows.
+
==Examples==
 
+
==Discussion ==
+
 
+
Programmers will often try to index from a pointer by adding a number of bytes, even though this is wrong, since C and C++ implicitly scale the operand by the size of the data type.
+
 
+
==Examples ==
+
  
 
<pre>
 
<pre>
Line 58: Line 53:
 
Note that the above code may also be wrong in other ways, particularly in a little endian environment.
 
Note that the above code may also be wrong in other ways, particularly in a little endian environment.
  
==Related problems ==
 
  
Not available.
+
==Related [[Attacks]]==
  
==Categories ==
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:General Logic Errors]]
+
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
 
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* Design: Use a platform with high-level memory abstractions.
 +
* Implementation: Always use array indexing instead of direct pointer manipulation.
 +
* Other: Use technologies for preventing buffer overflows.
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
 +
 
 +
Encoding Vulnerability
 +
 
 +
Error Handling Vulnerability
 +
 
 +
Input Validation Vulnerability
 +
 
 +
Logging and Auditing Vulnerability
 +
 
 +
Session Management Vulnerability]]
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:General Logic Error Vulnerability]]
 +
[[Category:OWASP_CLASP_Project]]
 +
[[Category:C]]

Latest revision as of 08:23, 1 March 2009

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


Last revision (mm/dd/yy): 03/1/2009

Vulnerabilities Table of Contents

Description

In C and C++, one may accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.

Consequences

Often results in buffer overflow conditions.

Exposure period

  • Design: Could choose a language with abstractions for memory access.
  • Implementation: This problem generally is due to a programmer error.

Platform

C and C++.

Required resources

Any

Severity

High

Likelihood of exploit

Medium

Programmers will often try to index from a pointer by adding a number of bytes, even though this is wrong, since C and C++ implicitly scale the operand by the size of the data type.

Risk Factors

TBD

Examples

int *p = x;
char * second_char = (char *)(p + 1);

In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms).

If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory - whether or not it is a buffer overflow.

Note that the above code may also be wrong in other ways, particularly in a little endian environment.


Related Attacks


Related Vulnerabilities


Related Controls

  • Design: Use a platform with high-level memory abstractions.
  • Implementation: Always use array indexing instead of direct pointer manipulation.
  • Other: Use technologies for preventing buffer overflows.


Related Technical Impacts


References

TBD