Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

When performing pointer arithmetic, the size of the value to add to a pointer is automatically scaled to the size of the pointer's type. For instance, when adding a value to a pointer to a four-byte integer, the value is scaled by a factor of four and then added to the pointer. Failing to understand how pointer arithmetic works can lead to miscalculations that result in serious errors, such as buffer overflows.

Non-Compliant Code Example 1

Wiki Markup
In this non-compliant code example derived from \[[Dowd|AA. C References#Dowd 06]\], integer values returned by {{parseint(getdata())}} are stored into an array of {{INTBUFSIZE}} elements of type {{int}} called {{buf}}.  If data is available for insertion into {{buf}} (which is indicated by {{havedata()}}) and {{buf_ptr}} has not been incremented past {{buf + sizeof(buf)}}, an integer value is stored at the address referenced by {{buf_ptr}}. However, the {{sizeof}} operator returns the total number of bytes in {{buf}} which is typically a multiple of the number of elements in {{buf}}. This value is scaled to the size of an integer and added to {{buf}}. As a result, the check to make sure integers are not written past the end of {{buf}} is incorrect and a buffer overflow is possible.

Code Block
bgColor#FFCCCC
int buf[INTBUFSIZE];
int *buf_ptr = buf;

while (havedata() && buf_ptr < buf + sizeof(buf)) {
    *buf_ptr++ = parseint(getdata());
}

Compliant Solution 1

In this compliant solution, the size of buf is added directly to buf and used as an upper bound. The integer literal is scaled to the size of an integer and the upper bound of buf is checked correctly.

Code Block
bgColor#CCCCFF
int buf[INTBUFSIZE];
int *buf_ptr = buf;

while (havedata() && buf_ptr < (buf + INTBUFSIZE)) {
    *buf_ptr++ = parseint(getdata());
}

Non-Compliant Code Example 2

The following 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 results in the call to memset() writing to unintended memory.

Code Block
bgColor#FFCCCC
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 */
};
/* ... */
size_t skip = sizeof(unsigned long long);
struct big *s = malloc(sizeof(struct big));
if (!s) {
   /* Handle malloc() error */
}

memset(s + skip, 0, sizeof(struct big) - skip);
/* ... */
free(s);

Compliant Solution 2

To correct this example, the struct big pointer is cast as a char *. This causes skip_member to be scaled by a factor of 1.

Code Block
bgColor#CCCCFF
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 */
};
/* ... */
size_t skip = sizeof(unsigned long long);
struct big *s = malloc(sizeof(struct big));
if (!s) {
   /* Handle malloc() error */
}

memset((char *)s + skip, 0, sizeof(struct big) - skip);
/* ... */
free(s);

Risk Assessment

Failure to understand and properly use pointer arithmetic can allow an attacker to execute arbitrary code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP08-A

3 (high)

2 (probable)

1 (high)

P6

L2

Examples of vulnerabilities resulting from the violation of this rule can be found on the CERT website.

Reference

Wiki Markup
\[[Dowd|AA. C References#Dowd 06]\] Chapter 6, "C Language Issues" (Vulnerabilities)
\[[cnst: 10-year-old pointer-arithmetic bug in make(1) is now gone, thanks to malloc.conf and some debugging|http://cnst.livejournal.com/24040.html]\]