Page History

Dynamic memory managers are not required to clear freed memory and generally do not because of the additional runtime overhead.  Furthermore, dynamic memory managers are free to reallocate this same memory.  As a result, it is possible to accidently leak sensitive information if it is not cleared before calling a function which frees, or may free, dynamic memory.  A example of this risk is the "Sun tarball" vulnerability described in [Graff 03].  Programmers cannot rely on memory being cleared during allocation either \[[MEM33-C. Do not assume memory allocation routines initialize memory]\].

In practice, this type of security flaw can expose sensitive information to unintended parties. The Sun tarball vulnerability discussed in _Secure Coding Principles & Practices: Desigining and Implementing Secure Applications_ \[[Graf 03|AA. C References#Graf 03]\] and [Sun Security Bulletin #00122 | http://sunsolve.sun.com/search/document.do?assetkey=1-22-00122-1] illustrates a violation of this recommendation leading to sensitive data being leaked. Attackers may also be able to leverage this defect to retrieve sensitive information using techniques, such as _heap inspection_

Calling free() on a block of dynamic memory marks that memory for deallocation. Once deallocated, the block of memory is made available for future allocation. However, the data stored in the block of memory to be recycled may be preserved. If this memory block contains sensitive information, that information may be unintentionally exposed.

This scenario can lead to information leakage; for instance, as is described in Rule: MEM33-C. Do not assume memory allocation routines initialize memory. Attackers may also be able to leverage this defect to retrieve sensitive information using techniques, such as heap inspection

.

To prevent information leakage it is necessary to clear sensitive information from dynamically allocated buffers before they are freed.

Non-Compliant Code Example

...

: free()

Calling free() on a block of dynamic memory causes the space to be deallocated, that is, the memory block is made available for future allocation. However, the data stored in the block of memory to be recycled may be preserved. If this memory block contains sensitive information, that information may be unintentionally exposed.

In this example, sensitive information in stored in the buffer dynamically allocated memory referenced by secret is copied to the dynamically allocated buffer, new_secret, which is then processed and eventually marked for deallocation with deallocated by a call to free(). However, the contents of new_secret may remain in heap memory after being marked for deallocation. Furthermore, if this memory is recycled by the heap manager, Because the memory is not cleared, it may be reallocated to another section of the program where the information stored in new_secret may be exposed to another, unintended section of the program, or another program entirelyunintentionally linked.

...
char *new_secret;
size_t size = strlen(secret);
if (size == SIZE_MAX) {
  /* Handle Error */
}

new_secret = malloc(size+1);
if (!new_secret) {
  /* Handle Error */
}
strcpy(new_secret, secret);

/* Process new_secret... */

free(new_secret);
...

Compliant Solution

...

: free()

To prevent information leakage, dynamic memory containing sensitive information should be sanitized before it is marked for deallocation. Below, this is done by filling the allocated space with {{This is commonlly accomplished by clearing the allocated space (that is, filling the space with '\0'}} characters. Note that {{calloc()}} is also used to zero-out newly allocated memory. Note that because {{sizeof(char)}} is guaranteed to be 1, this solution does not need to check for a numeric overflow as a result of using {{calloc()}} \[[MEM37-C | MEM37-C. Ensure that size arguments to calloc() do not result in an integer overflow]\].

...
char *new_secret;
size_t size = strlen(secret);
if (size == SIZE_MAX) {
  /* Handle Error */
}

new_secret = calloc(size+1,sizeof(char)); /* use calloc() to zero-out allocated space */
if (!new_secret) {
  /* Handle Error */
}
strcpy(new_secret, secret);

/* Process new_secret... */

memset(new_secret,'\0',size); /* sanitize memory  */
free(new_secret);
...

The {{calloc()}} function is used in this example to ensure that the newly allocated memory has also be cleared. Because {{sizeof(char)}} is guaranteed to be 1, this solution does not need to check for a numeric overflow as a result of using {{calloc()}} \[[MEM37-C | MEM37-C. Ensure that size arguments to calloc() do not result in an integer overflow]\].

Non-Compliant Code Example

...

: realloc()

Using {{realloc()}} to resize dynamic memory may inadvertently expose sensitive information, or allow heap inspection as is described in Fortify's Taxonomy of Software Security Errors \[[vulncat|http://vulncat.fortifysoftware.com/2/HI.html]\] and NIST's Source Code Analysis Tool Functional Specification \[[SAMATE]\]. When {{realloc()}} is called it may allocate a new, larger block of memory, copy the contents, of {{secret}} to this new block, {{free()}} the original block, and assign the newly allocated block to {{secret}}. However, the contents of the original block may remain in heap memory after being marked for deallocation.

...
secret = realloc(secret ,new_size);
...

Compliant Solution

...

: {realloc()}}

Correcting this example requires the programmer to write a custom routine that operates similar to realloc(), but sanitizes sensitive information as heap-based buffers are resized. First, a new, resized block of memory is allocated (note that calloc() is used to ensure its contents are properly initialized). Second, the contents of secret are copied to this new space. Next, the memory referred to by secret is sanitized by overwriting its contents with '\0' characters. Next, the memory referred to by secret is then free()'d. Finally, the newly allocated space is installed, taking care to remove all unneeded references to the new space.

...

http://vulncat.fortifysoftware.com/2/HI.html
http://samate.nist.gov/docs/SAMATE_source_code_analysis_tool_spec_09_15_06.pdf
MEM33-C. Do not assume memory allocation routines initialize memory Graff 03 Graff, Mark G. and van Wyk, Kenneth R. Secure Coding Principles & Practices: Desigining and Implementing Secure Applications. Sebastopol, CA: O'Reilly & Associates, 2003 (ISBN 0-596-00242-4).