When performing pointer arithmetic, the size of the computation value to add to a pointer is automatically scaled to the size of the pointer type of the pointed-to object. For instance, when adding a pointer value to the byte address of a four4-byte integer will be , the value is scaled by four bytes at a time.Improper use of pointer arithmetic a factor of 4 and then added to the pointer. Failing to understand how pointer arithmetic works can lead to miscalculations that result in subtle and hard to spot coding errors.
...
serious errors, such as buffer overflows.
Noncompliant Code Example
In this example, taken from dowd, buf_ptr
is used to insert new integers into buf
, which is an array of 1024 integers. If there is data to be inserted noncompliant code example, integer values returned by parseint(getdata())
are stored into an array of INTBUFSIZE
elements of type int
called buf
[Dowd 2006]. If data is available for insertion into buf
(which is indicated by havedata()
) and buf_ptr
has not been incremented past buf + sizeof(buf)
, then an integer is inserted into buf
via value is stored at the address referenced by buf_ptr
. However, the sizeof
operator returns the total number of bytes in buf
, which , assuming four-byte integers, is 4096 bytesis typically a multiple of the number of elements in buf
. This value is then scaled to the size of an integer and added to buf
. As a result, it is possible to write integers the check to make sure integers are not written past the end of buf
is incorrect, and cause a buffer overflow is possible.
Code Block | ||||
---|---|---|---|---|
| ||||
int buf[1024INTBUFSIZE]; int *buf_ptr = buf; while (havedata() && buf_ptr < (buf + sizeof(buf))) { *buf_ptr++ = parseint(getdata()); } |
While at first look this code appears correct and that it will prevent overflowing the allocated buffer, in fact buf + sizeof(buf) returns a value corresponding to a region in memory beyond the allocated buffer. This is due to buf
being an int pointer and the result of sizeof(buf) getting multiplied by sizeof(int) accordingly. Thus, this code is vulnerable to buffer overflow.
Compliant Code Examples
1)
Compliant Solution
In this compliant solution, the size of buf
, INTBUFSIZE
, is added directly to buf
and used as an upper bound. The integer literal INTBUFSIZE
is scaled to the size of an integer, and the upper bound of buf
is checked correctly.
Code Block | ||||
---|---|---|---|---|
| ||||
int buf[INTBUFSIZE | ||||
Code Block | ||||
| ||||
int buf[BUF_LEN]; int *buf_ptr = buf; while (havedata() && buf_ptr < buf[BUF_LEN-1]) (buf + INTBUFSIZE)) { *buf_ptr++ = parseint(getdata()); buf_ptr++; } |
2)An arguably better solution is to use the address of the nonexistent element following the end of the array, as follows:
Code Block | ||||
---|---|---|---|---|
| ||||
int buf[1024INTBUFSIZE]; int *bbuf_ptr = buf; while (havedata() && bbuf_ptr < &buf[INTBUFSIZE]) { *buf+sizeof(buf)) { *b++ = parseint(getdata()); } |
These corrected versions:
- eliminate the coding error of the original code
- maintain clarity of intended result while reading code
Risk Analysis
Failure to notice a coding error of this variety would easily become a buffer overflow vulnerability. In a worst case scenario this could lead to arbitrary code execution and thus hold severe risk.
Reference
...
_ptr++ = parseint(getdata());
}
|
This solution works because the C Standard guarantees the address of buf[INTBUFSIZE]
even though no such element exists.
Noncompliant Code Example
This noncompliant code example is based on a flaw in the OpenBSD operating system. An integer, skip
, is added as an offset to a pointer of type struct big
. The adjusted pointer is then used as a destination address in a call to memset()
. However, when skip
is added to the struct big
pointer, it is automatically scaled by the size of struct big
, which is 32 bytes (assuming 4-byte integers, 8-byte long long
integers, and no structure padding). This scaling results in the call to memset()
writing to unintended memory.
Code Block | ||||
---|---|---|---|---|
| ||||
struct big {
unsigned long long ull_1; /* Typically 8 bytes */
unsigned long long ull_2; /* Typically 8 bytes */
unsigned long long ull_3; /* Typically 8 bytes */
int si_4; /* Typically 4 bytes */
int si_5; /* Typically 4 bytes */
};
/* ... */
int f(void) {
size_t skip = offsetof(struct big, ull_2);
struct big *s = (struct big *)malloc(sizeof(struct big));
if (!s) {
return -1; /* Indicate malloc() failure */
}
memset(s + skip, 0, sizeof(struct big) - skip);
/* ... */
free(s);
s = NULL;
return 0;
} |
A similar situation occurred in OpenBSD's make
command [Murenin 2007].
Compliant Solution
To correct this example, the struct big
pointer is cast as a char *
, which causes skip
to be scaled by a factor of 1:
Code Block | ||||
---|---|---|---|---|
| ||||
struct big {
unsigned long long ull_1; /* Typically 8 bytes */
unsigned long long ull_2; /* Typically 8 bytes */
unsigned long long ull_3; /* Typically 8 bytes */
int si_4; /* Typically 4 bytes */
int si_5; /* Typically 4 bytes */
};
/* ... */
int f(void) {
size_t skip = offsetof(struct big, ull_2);
struct big *s = (struct big *)malloc(sizeof(struct big));
if (!s) {
return -1; /* Indicate malloc() failure */
}
memset((char *)s + skip, 0, sizeof(struct big) - skip);
/* ... */
free(s);
s = NULL;
return 0;
} |
Risk Assessment
Failure to understand and properly use pointer arithmetic can allow an attacker to execute arbitrary code.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP08-C | High | Probable | High | P6 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| Supported: Astrée reports potential runtime errors resulting from invalid pointer arithmetics. | |||||||
CodeSonar |
| LANG.STRUCT.PARITH | Pointer arithmetic | ||||||
Helix QAC |
| C0488, C2930, C2931, C2932, C2933 | |||||||
Klocwork |
| ABV.ITERATOR ABV.GENERAL ABV.GENERAL.MULTIDIMENSION | |||||||
LDRA tool suite |
| 45 D | Partially implemented | ||||||
Parasoft C/C++test |
| CERT_C-EXP08-a | Pointer arithmetic should not be used | ||||||
Parasoft Insure++ | Runtime analysis | ||||||||
PC-lint Plus |
| 416 | Partially supported | ||||||
Polyspace Bug Finder |
| Checks for:
Rec. fully supported. | |||||||
PVS-Studio |
| V503, V520, V574, V600, V613, V619, V620, V643, V650, V687, V769, V1004 |
How long is 4 yards plus 3 feet? It is obvious from elementary arithmetic that any answer involving 7 is wrong, as the student did not take the units into account. The right method is to convert both numbers to reflect the same units.
The examples in this rule reflect both a correct and an incorrect way to handle comparisons of numbers representing different things (either single bytes or multibyte data structures). The noncompliant examples just add the numbers without regard to units, whereas the compliant solutions use type casts to convert one number to the appropriate unit of the other number.
ROSE can catch both noncompliant examples by searching for pointer arithmetic expressions involving different units. The "different units" is the tricky part, but you can try to identify an expression's units using some simple heuristics:
- A pointer to a
foo
object hasfoo
as the unit. - A pointer to
char *
has byte as the unit. - Any
sizeof
oroffsetof
expression also has unit byte as the unit. - Any variable used in an index to an array of
foo
objects (e.g.,foo[variable]
) hasfoo
as the unit.
In addition to pointer arithmetic expressions, you can also hunt for array index expressions, as array[index]
is merely shorthand for "array + index
."
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
SEI CERT C++ Coding Standard | VOID EXP08-CPP. Ensure pointer arithmetic is used correctly |
ISO/IEC TR 24772:2013 | Pointer Casting and Pointer Type Changes [HFC] Pointer Arithmetic [RVG] |
ISO/IEC TS 17961 | Forming or using out-of-bounds pointers or array subscripts [invptr] |
MISRA C:2012 | Rule 18.1 (required) Rule 18.2 (required) Rule 18.3 (required) Rule 18.4 (advisory) |
MITRE CWE | CWE-468, Incorrect pointer scaling |
Bibliography
[Dowd 2006] | Chapter 6, "C Language Issues" |
[Murenin 2007] |
...