...
Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element of the array, so for any iterator type there is an iterator value that points past the last element of a corresponding container. These values are called past-the-end values. Values of an iterator i for which the expression *i is defined are called dereferenceable. The library never assumes that past-the-end values are dereferenceable.
Noncompliant Code Example (Arrays)
In this noncompliant code example, a pointer is set to reference the start of an array. Array elements are accessed sequentially within the for loop. The array pointer ip is incremented on each iteration.
...
This code also suffers from using "magic numbers," described in DCL06-CPP. Use meaningful symbolic constants to represent literal values in program logic. When replacing the numbers with constants, a developer is likely to catch the invalid array bounds in the for statement.
Compliant Solution (Arrays)
This compliant solution fixes the problem from the previous noncompliant code example by using the common idiom sizeof(ar)/sizeof(ar[0]) to determine the actual number of elements in the array. This idiom works only when the definition of the array is visible (see CTR01-CPP. Do not apply the sizeof operator to a pointer when taking the size of an array).
...
C++2003 guarantees that it is permissible to use the address of ar[sizeof(ar)/sizeof(ar[0])] even though no such element exists. This allows you to use it for checks in loops like the one in this Compliant Solution. The guarantee extends only to one element beyond the end of an array and no further Banahan 03.
Noncompliant Code Example (Vectors)
In this noncompliant code example, an iterator is set to reference the beginning of a vector. Vector elements are accessed sequentially within the for loop. The iterator ip is incremented on each iteration.
...
This code also suffers from using "magic numbers," described in DCL06-CPP. Use meaningful symbolic constants to represent literal values in program logic. When replacing the numbers with constants, a developer is likely to catch the invalid bounds in the for statement.
Compliant Solution (Vectors)
This compliant solution fixes the problem from the previous noncompliant code example by using the ranges ar.begin() and ar.end() to determine how many iterations should be executed.
...
Since the iterator::end() method returns an iterator pointing to one element past the end of the vector, it functions as a useful loop terminator.
Non-Compliant Code Example (Linear Address Space)
Pointer arithmetic can result in undefined behavior if the pointer operand and the resulting pointer do not refer to the same array object (or one past the last element of the array object). Compiler implementations are provided broad latitude by the standard in how to deal with undefined behavior (see MSC15-CPP. Do not depend on undefined behavior) including ignoring the situation completely with unpredictable results.
...
This code resembles the test for wraparound from the sprint() function as implemented for the Plan 9 operating system. If buf + len < buf evaluates to true, len is assigned the remaining space minus 1 byte. However, because the expression buf + len < buf constitutes undefined behavior, compilers can assume this condition will never occur and optimize out the entire conditional statement. In gcc versions 4.2 and later, for example, code that performs checks for wrapping that depend on undefined behavior (such as the code in this noncompliant code example) are optimized away; no object code to perform the check appears in the resulting executable program [VU#162289]. This is of special concern because it often results in the silent elimination of code that was inserted to provide a safety or security check. For gcc version 4.2.4 and later, this optimization may be disabled for with the -fno-strict-overflow option.
Compliant Solution (Linear Address Space)
In this compliant solution, both references to buf are cast to size_t. Because {[size_t}} is an unsigned type, C++2003 guarantees that it has modulo behavior.
...
This compliant solution works on architectures that provide a linear address space. Some word-oriented machines are likely to produce a word address with the high-order bits used as a byte selector, in which case this solution will fail. Consequently, this is not a portable solution.
Non-Compliant Code Example (Pointer Addition)
Another interesting case is shown in this noncompliant code example. The expression buf + n may wrap for large values of n, resulting in undefined behavior.
...
This is an example of how optimization may actually help improve security. When compiled using GCC 4.3.0 with the -O2 option, for example, the expression buf + n < buf + 100 is optimized to n < 100, eliminating the possibility of wrapping. This code example is still noncompliant, because it is not safe to rely on compiler optimizations for security.
Compliant Solution (Pointer Addition)
In this compliant solution, the "optimization" is performed by hand.
| Code Block | ||||
|---|---|---|---|---|
| ||||
int process_array(char *buf, size_t n) {
return n < 100;
}
|
Risk Assessment
If adding or subtracting an integer to a pointer results in a reference to an element outside the array or one past the last element of the array object, the behavior is undefined, but frequently leads to a buffer overflow or buffer underrun which can often be exploited to run arbitrary code. Iterators and STL containers exhibit the same behavior and caveats as pointers and arrays.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
ARR38-CPP | high | likely | medium | P18 | L1 |
Automated Detection
Compass/ROSE could detect violations of this rule. At least it can catch all of the NCCE's.
...
Tool | Version | Checker | Description | ||||||
| 2930, 2931, 2932, 2933, 2934, 2950, 2951, 2952, 2953 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
This rule appears in the C Secure Coding Standard as VOID Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element.
References
[Banahan 03] Section 5.3, "Pointers," and Section 5.7, "Expressions involving pointers"
[ISO/IEC 14882-2003] Section 18.7
[MITRE 07] CWE ID 129, "Unchecked Array Indexing"
[VU#162289]
...
CTR37-CPP. Do not add or subtract an integer to a pointer to a non-array object 06. Containers (CTR) ARR39CTR39-CPP. Do not treat arrays polymorphicallyuse pointer arithmetic on polymorphic objects