SEI CERT C Coding Standard

Space shortcuts

Page tree

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

Compare with Current View Page History

« Previous Version 49 Next »

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. An 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: Designing and Implementing Secure Applications [[Graf 03]] and Sun Security Bulletin #00122 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.

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 stored in the dynamically allocated memory referenced by secret is copied to the dynamically allocated buffer, new_secret, which is processed and eventually deallocated by a call to free(). 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 unintentionally leaked.

...
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 being freed. This is commonly accomplished by clearing the allocated space (that is, filling the space with '\0' characters).

...
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 ensures 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 ]].

Non-Compliant Code Example: realloc()

Reallocating memory using the realloc() function is a degenerative case of freeing memory. The realloc() function function deallocates the old object and returns a pointer to a new object.

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 object, copy the contents, of secret to this new object, free() the original object, and assign the newly allocated object to secret. However, the contents of the original object may remain in memory.

...
...
size_t secret_size;
...
if (secret_size > SIZE_MAX/2) {
   /* handle error condition */
}

secret = realloc(secret, secret_size * 2);
...

A test is added at the beginning of this code to make sure that the integer multplication does not result in an integer overflow [[INT32-C]].

Compliant Solution: realloc()

A compliant program cannot rely on realloc() because it is not possible to clear the memory prior to the call.
Instead, a custom function that operates similar to realloc(), but sanitizes sensitive information as heap-based buffers are resized. Again, this is done by overwriting the space to be deallocated with '\0' characters.

...
size_t secret_size, new_secret_size;
...
if (secret_size > SIZE_MAX/2) {
   /* handle error condition */
}

temp_buff = calloc(secret_size * 2, sizeof(char)); /* calloc() initializes memory to zero */
if (temp_buff == NULL) {
 /* Handle Error */
}

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

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

The calloc() function ensures 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 ]].

Risk Assessment

Failure to clear dynamic memory can result in leaked information.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MEM03-A

2 (medium)

1 (unlikely)

3 (low)

P6

L2

References

  • No labels