Versions Compared

Key

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

...

The manner in which sensitive information can be properly cleared varies depending on the resource type and platform.

Noncompliant Code Example (free())

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 accidentally leak sensitive information if it is not cleared before calling a function that frees dynamic memory. Programmers also cannot rely on memory being cleared during allocation (see MEM09-C. Do not assume memory allocation routines initialize memory).

...

Code Block
bgColor#FFcccc
char *secret;

/* initialize secret */

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

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

/* Process new_secret... */

free(new_secret);
new_secret = NULL;

Compliant Solution

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

...

See MSC06-C. Be aware of compiler optimization when dealing with sensitive data for a definition and discussion of using the memset_s() function.

Noncompliant Code Example: realloc()

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

...

The secret_size is tested to ensure that the integer multiplication (secret_size * 2) does not result in an integer overflow (see INT32-C. Ensure that operations on signed integers do not result in overflow).

Compliant Solution

A compliant program cannot rely on realloc() because it is not possible to clear the memory prior to the call. Instead, a custom function must be used 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.

...

The calloc() function ensures that the newly allocated memory has also been 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() (see MEM07-C. Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t).

Risk Assessment

Wiki Markup
In practice, this type of [security flaw|BB. Definitions#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|AA. C References#Graf 03]\] and Sun Security Bulletin #00122 \[[Sun|AA. C References#Sun]\] shows 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_.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MEM03-C

medium

unlikely

high

P2

L3

Automated Detection

Klocwork Version 8.0.4.16 can detect violations of this rule with the SV.USAGERULES.UNINTENDED_COPY checkers.

Compass/ROSE could detect possible violations of this rule by first flagging any usage of realloc(). Also it could flag any usage of free that isn't preceded by code to clear out the preceding memory, using memset. This heuristic is imperfect, as it flags all possible data leaks, not just leaks of 'sensitive' data, because ROSE can't tell which data is 'sensitive'.

Related Vulnerabilities

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

Other Languages

This rule appears in the C++ Secure Coding Standard as MEM03-CPP. Clear sensitive information stored in reusable resources returned for reuse.

References

Wiki Markup
\[[Black 07|AA. C References#Black 07]\]
\[[Fortify 06|AA. C References#Fortify 06]\]
\[[Graff 03|AA. C References#Graf 03]\]
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.20.3, "Memory management functions"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "XZK Sensitive Information Uncleared Before Use"

...