MEM03-A. Clear sensitive information stored in dynamic memory prior to deallocation

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 1

In this example, sensitive information in stored in the buffer secret is copied to the dynamically allocated buffer, new_secret, which is then processed and eventually marked for deallocation with 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, the information stored in new_secret may be exposed to another, unintended section of the program, or another program entirely.

...
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 1

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 '\0' characters. Note that calloc() is also used to zero-out newly allocated memory.

...
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);
...

Non-Compliant Code Example 2

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] 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 2

...
temp_buff = calloc(new_size,sizeof(char)); /* use calloc() to zero-out allocated space */
if (temp_buff == NULL) {
 /* Handle Error */
}

memcpy(temp_buff, secret , secret_size);
memset(buffer,'\0',secret_size);         /* sanitize the buffer */

free(secret);
secret = temp_buff;                      /* install the resized buffer */
temp_buff = NULL;
...

Risk Assessment

Failure to clear dynamic memory can result in leaked information.

References

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