Versions Compared

Key

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

Wiki Markup
According to the WG14 document \[1\]:

...

Effective type of an object is defined as either its declared type or (in case its type hasn't been declared) the effective type of the value assigned to it. In the examples below, we have used terms like 'effective type of pointer p' which implies that if the type of 'p' has been declared (eg: char *p) then that type (in this case char) is the effective type of the pointer. If the type is not declared (eg: void *p) and then the pointer is assigned a value (p = obj), then the effective type of 'p' is the effective type of 'obj'.

Rule Description:

C library functions that make changes to arrays or objects usually take at least two arguments: i.) a pointer to the array/object ii.) an integer indicating the number of elements or bytes to be manipulated. If the arguments are supplied improperly during such a function call, the function may cause the pointer to not point to the object at all or point past the end of the object. This would lead to undefined behavior. 

...

  • For func (p,n), where 'p' is a pointer, 'n' is an integer and 'func' is a library function, the value of â€˜n’ should not be greater than the effective size of the pointer. Also, in situations where 'n' is an expression (see non-compliant code/compliant solution 2 below) the effective type of the pointer should be compatible with either the derived type of 'n' or unsigned char.
  • For func (p,q, n), where 'p' and 'q' are both pointers, 'n' is an integer and 'func' is a library function, the value of â€˜n’ should not be greater than the effective size of any of the two pointers ('p' and 'q'). The effective type of the 'p' should be compatible with the derived type of 'n' or unsigned char when 'n' is an expression. Similarly, the effective type of the 'p' should be compatible with the effective type of 'q' or unsigned char.
  • For expression E of the form: T* q = func (n), where 'func' is a memory allocation function, the value of 'n' should not be less than sizeof (T). Also, the effective type of 'T' should be compatible with either the derived type of 'n' or unsigned char.

...

List of library functions to which the above rules can apply:

...

memcpy()

memmove()

memset() 

 

wmemcpy()

wmemmove() 

strftime() 

 

calloc() 

malloc()

realloc()

 

strncpy()

swprintf()

vswprintf()

 

wcsncpy()

strxfrm()

snprintf() 

 

vsnprintf() 

fwrite() * 

fread() * 

 

* - both the functions take more than one size_t argument. In such cases, the compliant code will have to be changed according to the purpose of these arguments. For example in the case of fread():

                                    size_t fread ( void *ptr, size_t size, size_t count, FILE * stream)

    the programmer should make sure that the memory block to which 'ptr' points is of at least (size*count) bytes.

Noncompliant Code Example

...

Code Block
bgColor#ccccff
wchar_t *f7() {

	const wchar_t *p = L"Hello, World!";
	const size_t n = sizeof(wchar_t) * (wcslen(p) + 1);

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

}

Given below is a non-exhaustive list of library functions to which the above rules can apply:

memcpy()

memmove()

memset()

 

wmemcpy()

wmemmove()

strftime()

 

calloc()

malloc()

realloc()

 

strncpy()

swprintf()

vswprintf()

 

wcsncpy()

strxfrm()

snprintf()

 

vsnprintf()

fwrite() *

fread() *

 

* - both the functions take more than one size_t argument. In such cases, the compliant code will have to be changed according to the purpose of these arguments. For example in the case of fread():

                                    size_t fread ( void *ptr, size_t size, size_t count, FILE * stream)

...

Risk Assessment

Depending on the library function called, the attacker may be able to use a heap overflow vulnerability to run arbitrary code. The detection of checks specified in description can be automated but the remediation has to be manual.

...