Difference between revisions of "Unintentional pointer scaling"

Jump to: navigation, search
Line 1: Line 1:
[[ASDR Table of Contents]]
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

Revision as of 21:00, 20 February 2009

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

Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents


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


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.


C and C++.

Required resources




Likelihood of exploit


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



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