CERT
Skip to end of metadata
Go to start of metadata

C library functions that make changes to arrays or objects take at least two arguments: a pointer to the array or object and an integer indicating the number of elements or bytes to be manipulated. For the purposes of this rule, the element count of a pointer is the size of the object to which it points, expressed by the number of elements that are valid to access. Supplying arguments to such a function might cause the function to form a pointer that does not point into or just past the end of the object, resulting in undefined behavior.

Annex J of the C Standard [ISO/IEC 9899:2011] states that it is undefined behavior if the "pointer passed to a library function array parameter does not have a value such that all address computations and object accesses are valid." (See undefined behavior 109.)

In the following code,

the element count of the pointer p is sizeof(arr) / sizeof(arr[0]), that is, 5. The element count of the pointer p2 is sizeof(arr), that is, 20, on implementations where sizeof(int) == 4. The element count of the pointer p3 is 12 on implementations where sizeof(int) == 4, because p3 points two elements past the start of the array arr.  The element count of p4 is treated as though it were unsigned char * instead of void *, so it is the same as p2.

Pointer + Integer

The following standard library functions take a pointer argument and a size argument, with the constraint that the pointer must point to a valid memory object of at least the number of elements indicated by the size argument.

fgets()fgetws()mbstowcs()1 wcstombs()1
mbrtoc16()2 mbrtoc32()2mbsrtowcs()1wcsrtombs()1
mbtowc()2 mbrtowc()1 mblen()mbrlen()
memchr()wmemchr()memset()wmemset()
strftime()wcsftime()strxfrm()1wcsxfrm()1
strncat()2 wcsncat()2snprintf()vsnprintf()
swprintf()vswprintf()setvbuf()tmpnam_s()
snprintf_s()sprintf_s() vsnprintf_s()vsprintf_s()
gets_s() getenv_s()wctomb_s()mbstowcs_s()3
wcstombs_s()3memcpy_s()3memmove_s()3strncpy_s()3
strncat_s()3strtok_s()2strerror_s()strnlen_s()
asctime_s()ctime_s()snwprintf_s()swprintf_s()
vsnwprintf_s()vswprintf_s()wcsncpy_s()3wmemcpy_s()3
wmemmove_s()3wcsncat_s()3wcstok_s()2wcsnlen_s()
wcrtomb_s()mbsrtowcs_s()3wcsrtombs_s()3memset_s()4

1 Takes two pointers and an integer, but the integer specifies the element count only of the output buffer, not of the input buffer.
2 Takes two pointers and an integer, but the integer specifies the element count only of the input buffer, not of the output buffer.
3 Takes two pointers and two integers; each integer corresponds to the element count of one of the pointers.
4 Takes a pointer and two size-related integers; the first size-related integer parameter specifies the number of bytes available in the buffer; the second size-related integer parameter specifies the number of bytes to write within the buffer.

For calls that take a pointer and an integer size, the given size should not be greater than the element count of the pointer.

 Noncompliant Code Example (Element Count)

In this noncompliant code example, the incorrect element count is used in a call to wmemcpy(). The sizeof operator returns the size expressed in bytes, but wmemcpy() uses an element count based on wchar_t *.

Compliant Solution (Element Count)

When using functions that operate on pointed-to regions, programmers must always express the integer size in terms of the element count expected by the function. For example, memcpy() expects the element count expressed in terms of void *, but wmemcpy() expects the element count expressed in terms of wchar_t *.  Instead of the sizeof operator, functions that return the number of elements in the string are called, which matches the expected element count for the copy functions. In the case of this compliant solution, where the argument is an array A of type T, the expression sizeof(A) / sizeof(T), or equivalently sizeof(A) / sizeof(*A), can be used to compute the number of elements in the array.

Noncompliant Code Example (Pointer + Integer)

This noncompliant code example assigns a value greater than the number of bytes of available memory to n, which is then passed to memset():

Compliant Solution (Pointer + Integer)

This compliant solution ensures that the value of n is not greater than the number of bytes of the dynamic memory pointed to by the pointer p:

Noncompliant Code Example (Pointer + Integer)

In this noncompliant code example, the element count of the array a is ARR_SIZE elements. Because memset() expects a byte count, the size of the array is scaled incorrectly by sizeof(int) instead of sizeof(long), which can form an invalid pointer on architectures where sizeof(int) != sizeof(long).

Compliant Solution (Pointer + Integer)

In this compliant solution, the element count required by memset() is properly calculated without resorting to scaling:

Two Pointers + One Integer

The following standard library functions take two pointer arguments and a size argument, with the constraint that both pointers must point to valid memory objects of at least the number of elements indicated by the size argument. 

memcpy()wmemcpy()memmove()wmemmove()
strncpy()wcsncpy()memcmp()wmemcmp()
strncmp()wcsncmp()strcpy_s()wcscpy_s()
strcat_s()wcscat_s()  

For calls that take two pointers and an integer size, the given size should not be greater than the element count of either pointer.

Noncompliant Code Example (Two Pointers + One Integer)

In this noncompliant code example, the value of n is incorrectly computed, allowing a read past the end of the object referenced by q:

Compliant Solution (Two Pointers + One Integer)

This compliant solution ensures that n is equal to the size of the character array:

One Pointer + Two Integers

The following standard library functions take a pointer argument and two size arguments, with the constraint that the pointer must point to a valid memory object containing at least as many bytes as the product of the two size arguments.

bsearch()bsearch_s()qsort()qsort_s()
fread()fwrite()  

For calls that take a pointer and two integers, one integer represents the number of bytes required for an individual object, and a second integer represents the number of elements in the array. The resulting product of the two integers should not be greater than the element count of the pointer were it expressed as an unsigned char *.  

Noncompliant Code Example (One Pointer + Two Integers)

This noncompliant code example allocates a variable number of objects of type struct obj. The function checks that num_objs is small enough to prevent wrapping, in compliance with INT30-C. Ensure that unsigned integer operations do not wrap. The size of struct obj is assumed to be 16 bytes to account for padding to achieve the assumed alignment of long long. However, the padding typically depends on the target architecture, so this object size may be incorrect, resulting in an incorrect element count.

Compliant Solution (One Pointer + Two Integers)

This compliant solution uses the sizeof operator to correctly provide the object size and num_objs to provide the element count:

Noncompliant Code Example (One Pointer + Two Integers)

In this noncompliant code example, the function f() calls fread() to read nitems of type wchar_t, each size bytes in size, into an array of BUFFER_SIZE elements, wbuf. However, the expression used to compute the value of nitems fails to account for the fact that, unlike the size of char, the size of wchar_t may be greater than 1. Consequently, fread() could attempt to form pointers past the end of wbuf and use them to assign values to nonexistent elements of the array. Such an attempt is undefined behavior. (See undefined behavior 109.)  A likely consequence of this undefined behavior is a buffer overflow. For a discussion of this programming error in the Common Weakness Enumeration database, see CWE-121, "Stack-based Buffer Overflow," and CWE-805, "Buffer Access with Incorrect Length Value."

Compliant Solution (One Pointer + Two Integers)

This compliant solution correctly computes the maximum number of items for fread() to read from the file:

Noncompliant Code Example (Heartbleed)

CERT vulnerability 720951 describes a vulnerability in OpenSSL versions 1.0.1 through 1.0.1f, popularly known as "Heartbleed." This vulnerability allows an attacker to steal information that under normal conditions would be protected by Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption.

Despite the seriousness of the vulnerability, Heartbleed is the result of a common programming error and an apparent lack of awareness of secure coding principles. Following is the vulnerable code:

 

This code processes a "heartbeat" packet from a client. As specified in RFC 6520, when the program receives a heartbeat packet, it must echo the packet's data back to the client. In addition to the data, the packet contains a length field that conventionally indicates the number of bytes in the packet data, but there is nothing to prevent a malicious packet from lying about its data length.

The p pointer, along with payload and p1, contains data from a packet. The code allocates a buffer sufficient to contain payload bytes, with some overhead, then copies payload bytes starting at p1 into this buffer and sends it to the client. Notably absent from this code are any checks that the payload integer variable extracted from the heartbeat packet corresponds to the size of the packet data. Because the client can specify an arbitrary value of payload, an attacker can cause the server to read and return the contents of memory beyond the end of the packet data, which violates INT04-C. Enforce limits on integer values originating from tainted sources. The resulting call to memcpy() can then copy the contents of memory past the end of the packet data and the packet itself, potentially exposing sensitive data to the attacker. This call to memcpy() violates ARR38-C. Guarantee that library functions do not form invalid pointers. A version of ARR38-C also appears in ISO/IEC TS 17961:2013, "Forming invalid pointers by library functions [libptr]." This rule would require a conforming analyzer to diagnose the Heartbleed vulnerability.

 

Compliant Solution (Heartbleed)

OpenSSL version 1.0.1g contains the following patch, which guarantees that payload is within a valid range. The range is limited by the size of the input record.

Risk Assessment

Depending on the library function called, an attacker may be able to use a heap or stack overflow vulnerability to run arbitrary code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

ARR38-C

High

Likely

Medium

P18

L1

Automated Detection

Tool

Version

Checker

Description

Astrée17.04i Supported, but no explicit checker
CodeSonar4.4

LANG.MEM.BO
LANG.MEM.BU
BADFUNC.BO.*

Buffer overrun
Buffer underrun
A collection of warning classes that report uses of library functions prone to internal buffer overflows

Compass/ROSE

 

 

 

Coverity2017.07

BUFFER_SIZE

BAD_SIZEOF

BAD_ALLOC_STRLEN

BAD_ALLOC_ARITHMETIC

Implemented

Fortify SCA

5.0

 

Can detect violations of this rule with CERT C Rule Pack

Klocwork

2017

ABV.ANY_SIZE_ARRAY
ABV.GENERAL
ABV.ITERATOR
ABV.STACK
ABV.TAINTED
ABV.UNKNOWN_SIZE

 

LDRA tool suite9.5.664 X, 66 X, 68 X, 69 X, 70 X, 71 X, 79 X
Partially Implmented
Parasoft C/C++test9.5BD-PB-OVERF{RD,WR,FMT,NZT}Fully implemented
Parasoft Insure++  Runtime analysis
Polyspace Bug FinderR2016a

Array access out of bounds, Buffer overflow from incorrect string format specifier, Destination buffer overflow in string manipulation, Destination buffer underflow in string manipulation, Invalid use of standard library memory routine
Invalid use of standard library string routine, Mismatch between data length and size, Pointer access out of bounds
Possible misuse of sizeof, Use of tainted pointer

Guarantee that library functions do not form invalid pointers
PRQA QA-C9.3

2845, 2846, 2847, 2848, 2849, 2930, 2932, 2933, 2934

Fully implemented

Splint

3.1.1

 

 

Related Vulnerabilities

CVE-2016-2208 results from a violation of this rule. The attacker can supply a value used to determine how much data is copied into a buffer via memcpy(), resulting in a buffer overlow of attacker-controlled data.

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

C Secure Coding StandardAPI00-C. Functions should validate their parameters
ARR01-C. Do not apply the sizeof operator to a pointer when taking the size of an array
INT30-C. Ensure that unsigned integer operations do not wrap
ISO/IEC TS 17961:2013Forming invalid pointers by library functions [libptr]
ISO/IEC TR 24772:2013

Buffer Boundary Violation (Buffer Overflow) [HCB]
Unchecked Array Copying [XYW]

MITRE CWE

 

CWE-119, Improper Restriction of Operations within the Bounds of a Memory Buffer
CWE-121, Stack-based Buffer Overflow
CWE-123, Write-what-where Condition
CWE-125, Out-of-bounds Read
CWE-805, Buffer Access with Incorrect Length Value 

Bibliography

 


 

13 Comments

  1. Why not include this example?

    EXAMPLE 4 In the following function definition, assume that the effective size of *p and the effective size of *q are not determinable. Furthermore, the effective type of *p (that is, char) is compatible with effective type of *q (also char). However, effective type of *p (char) is not compatible with derived type of the expression n (pointer to char) and consequently the call to memcpy is diagnosed.

    For an assignment expression E whose right operand is a call to a memory allocation function taking an integer argument n, and the type of whose left operand is T*, or the equivalent initialization expression the expression E where (n < sizeof (T)) shall be diagnosed.

    For an assignment expression E whose right operand is a call to a memory allocation function taking an integer argument n, and the type of whose left operand is T *, or the equivalent initialization expression the expression E where T is compatible with neither the derived type of the expression n nor unsigned char shall be diagnosed.

  2. I've included the full definitions of "derived type" and "effective size" from CSGR and I left the simplified versions as well. This is probably incorrect, but I'm not sure which approach makes more sense.

  3. I'm very uncertain about the following notes:

    Note: While still noncompliant, this code does not constitute a vulnerability on implementations where sizeof(int) is equal to sizeof(float).

    Here are my concerns:

    1. If our goal is to make this version of the standard consistent with CSCR, diagnosing these violations is inconsistent with the San Francisco rule, particularly because this is being proposed as a rule and not a recommendation.
    2. These violations will need to be discovered manually if conforming analyzers are not required to diagnose.
    3. This sort of sets a precedence to identify all situations under which the noncompliant example is not dangerous.
  4. I seem to remember one of the final things we did in TS 17961 was to break out Allocating insufficient memory                                                                                                                     [insufmem] from this rule because this rule was too hard to express otherwise.  I think we need to remove the memory allocation functions from this rule (there are no examples) and probably create a new rule based on [insufmem] in the dynamic memory section of this standard.

  5. I think we should reorganized this section more or less as follows.

     

    To guarantee that a standard library function does not construct an out-of-bounds pointer, programmers must heed the following rules when using functions that operate on pointed-to regions:

    • Always express the integer size in terms of the effective size expected by the function.
      • Eg) memcpy() expects the effective size expressed in terms of void *, but wmemcpy() expects the effective size expressed in terms of wchar_t *.

    use the above as an example of effective size.  the guarantee language is too strong for this.

    • For calls that take a pointer and an integer size, the given size should not be greater than the effective size of the pointer.
    • For calls that take a two pointers and an integer size, the given size should not be greater than the effective size of either pointer.
    • For calls that take a pointer and two integers, generally accept one integer representing the size of an individual object, and a second integer representing the number of objects in the array.  The resulting product of the two integers should not be greater than the effective size of the pointer were it expressed as an unsigned char *.   See INT30-C. Ensure that unsigned integer operations do not wrap for more information.

    move the above to the subsections for each case.

    remove this  / or move to the new rule based on [insufmem]

  6. In each CS/NCE pair we make some generalization about functions that take certain parameters, but I think this might be better if move the function tables into each section and then say "for the following functions, x and y hold true".

    1. How does the new layout look to you?

  7. This second sentence was deleted from the book:

    "For the purposes of this rule, the element count of a pointer is the size of the object to which it points, expressed by the number of elements that are valid to access."

    Does anyone think it needs to be here?

    1. Well, this term is used heavily throughout this rule, so we need to reword the rule. (I presume we did this in the book, right?)

      A quick search for "element count" reveals that it occurs in no other rules, but in 2 recommendations: API02-C. Functions that read or write to or from an array should take an argument to specify the source or target size and EXP08-C. Ensure pointer arithmetic is used correctly. They should be reworded.

      1. I added the sentence back here.  The version in the book was not reworded.

  8. The examples and explaining text on the "Two pointers and one integer" could be made better. Here are some thoughts:

    The non-compliant code fragment does not really demonstrate the problem at hand, but rather the ARR01-C problem. The function parameter type char[] is actually a char* in the function body, thus the sizeof(p) is the size of the pointer, not the array. If we want to keep this example, the explanation of the problem could highlight this problem.

    One of the issues mentioned is that both the arrays need to have enough space for the memcpy. This could be illustrated e.g. with this piece of code:

     

     

    Compliant code could be

     

    Furthermore the current compliant code does not really solve the programmer's problem that the memcpy size should be determined inside the function. In the current code, the whole function is useless; memcpy can be directly called with the function arguments.

    I do not know any good solution to this problem, but one way to have the function determine the size could be to wrap the array into a struct:

    1. You are correct that our example is a bit too contrived. I've updated the example based on your suggestion, thanks!