Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  

CWE-468: Incorrect Pointer Scaling

Weakness ID: 468
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
ChildOfClassClass682Incorrect Calculation
+ Relevant to the view "Development Concepts" (CWE-699)
MemberOfCategoryCategory465Pointer Issues
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

ImplementationProgrammers may try to index from a pointer by adding a number of bytes. This is incorrect because C and C++ implicitly scale the operand by the size of the data type.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.


C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.


Technical Impact: Read Memory; Modify Memory

Incorrect pointer scaling will often result in buffer overflow conditions. Confidentiality can be compromised if the weakness is in the context of a buffer over-read or under-read.
+ Likelihood Of Exploit
+ Demonstrative Examples

Example 1

This example attempts to calculate the position of the second byte of a pointer.

Example Language:
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.

+ Potential Mitigations

Phase: Architecture and Design

Use a platform with high-level memory abstractions.

Phase: Implementation

Always use array indexing instead of direct pointer manipulation.

Phase: Architecture and Design

Use technologies for preventing buffer overflows.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPUnintentional pointer scaling
CERT C Secure CodingARR39-CExactDo not add or subtract a scaled integer to a pointer
CERT C Secure CodingEXP08-CEnsure pointer arithmetic is used correctly
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Pointer Arithmetic", Page 277.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submission DateSubmitterOrganizationSource
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, White_Box_Definitions
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unintentional Pointer Scaling

More information is available — Please select a different filter.
Page Last Updated: November 14, 2017