You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 80 Next »

C library functions that make changes to arrays or objects usually 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. If the arguments are supplied improperly during such a function call, it 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.

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

In the following code,

int arr[5];
int *p = arr;

unsigned char *p2 = (unsigned char *)arr;
unsigned char *p3 = arr + 2;
void *p4 = arr;

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

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 *.
  • 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.
  • For standard memory allocation functions, the size (possibly scaled, as in the case of calloc()) should not be less than the desired effective size of the object being allocated were it expressed as an unsigned char *.  See MEM07-C. Ensure that the arguments to calloc(), when multiplied, do not wrap for more information about calloc().

Standard Library Functions

The following are lists of C library functions to which this rule applies.

Library Functions That Take a Pointer and 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 bytes or wide characters (as appropriate) indicated by the size argument.

fgets()fgetws()mbstowcs()1wcstombs()1
mbrtoc16()2mbrtoc32()2mbsrtowcs()1wcsrtombs()1
mbtowc()2mbrtowc()1mblen()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 only specifies the length of the output buffer. not the input buffer.
2 Takes two pointers and an integer, but the integer only specifies the length of the input buffer, not the output buffer.
3 Takes two pointers and two integers; each integer corresponds to the length of one of the pointers.
4 Takes a pointer and two size-related integers; the first size-related integer parameter specifies the size of the buffer, the second size-related integer parameter specifies the number of bytes to write within the buffer.

Library Functions That Take Two Pointers and an 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 bytes or wide characters as appropriate, indicated by the size argument.

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

Library Functions That Take a Pointer and 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()  

Standard Memory Allocation Functions

The following are the standard memory allocation functions that take a size integer argument and return a pointer.

aligned_alloc()

calloc() 

malloc()

realloc() 

Noncompliant Code Example

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

#include <stdlib.h>
#include <string.h>
 
void f1(size_t nchars) {
  char *p = (char *)malloc(nchars);
  const size_t n = nchars + 1;

  memset(p, 0, n);
}

Compliant Solution

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

#include <stdlib.h>
#include <string.h>
 
void f1(size_t nchars) {
  char *p = (char *)malloc(nchars);
  const size_t n = nchars;

  memset(p, 0, n);
}

Noncompliant Code Example

In this noncompliant code example, the effective size 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(float), which can form an invalid pointer on architectures where sizeof(int) != sizeof(float).

#include <string.h>
 
void f2() {
  const size_t ARR_SIZE = 4;
  float a[ARR_SIZE];
  const size_t n = sizeof(int) * ARR_SIZE;
  void *p = a;

  memset(p, 0, n);
}

Compliant Solution

In this compliant solution, the effective size required by memset is properly calculated without resorting to scaling.

#include <string.h>
 
void f2() {
  const size_t ARR_SIZE = 4;
  float a[ARR_SIZE];
  const size_t n = sizeof(a);
  void *p = a;

  memset(p, 0, n);
}

Noncompliant Code Example

In this noncompliant code example, the value for n is calculated based on the size of a pointer instead of the size of a wchar_t.

#include <stdlib.h>
#include <wchar.h>
 
wchar_t *f4() {
  const wchar_t *p = L"Hello, World!";
  const size_t n = sizeof(p) * (wcslen(p) + 1);

  wchar_t *q = (wchar_t *)malloc(n);
  return q;
}

Compliant Solution

This compliant solution ensures that n is calculated based on the proper type:

#include <stdlib.h>
#include <wchar.h>
 
wchar_t *f4() {
  const wchar_t *p = L"Hello, World!";
  const size_t n = sizeof(*p) * (wcslen(p) + 1);

  wchar_t *q = (wchar_t *) malloc(n);
  return q;
}

Noncompliant Code Example

In this noncompliant example, a diagnostic is required because the value of n is not computed correctly, allowing a possible write past the end of the object referenced by p:

#include <string.h>
 
void f4(char p[], const char *q) {
  const size_t n = sizeof(p); 
  if ((memcpy(p, q, n)) == p) {  /* Violation */
  }
}

Compliant Solution

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

#include <string.h>
 
void f4(char p[], const char *q, size_t size_p) {
  const size_t n = size_p; 
  if ((memcpy(p, q, n)) == p) {
  }
}

Risk Assessment

Depending on the library function called, the attacker may be able to use a heap 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

PRQA QA-C
Unable to render {include} The included page could not be found.
 2931Fully implemented

Related Vulnerabilities

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

Related Guidelines

Bibliography

[ISO/IEC TS 17961]Programming Languages, Their Environments and System Software Interfaces

 


 

  • No labels