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 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 See guideline MEM09-C. Do not assume memory allocation routines initialize memory.).

To prevent information leakage, sensitive information must be cleared from dynamically allocated buffers before they are freed. 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.

...

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 See guideline MEM07-C. Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t.).

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

...

Using {{realloc()}} to resize dynamic memory may inadvertently expose sensitive information, or it may allow heap inspection as described in the _Fortify Taxonomy: Software Security Errors_ \[[Fortify 062006|AA. Bibliography#Fortify 06]\] and NIST's _Source Code Analysis Tool Functional Specification_ \[[Black 072007|AA. Bibliography#Black 07]\]. 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.

...

The secret_size is tested to ensure that the integer multiplication (secret_size * 2) does not result in an integer overflow. (see See guideline 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 See guideline MEM07-C. Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t.).

Risk Assessment

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 032003|AA. Bibliography#Graf 03]\] and Sun Security Bulletin #00122 \[[Sun|AA. Bibliography#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_.

Automated Detection

...

...

...

Related Vulnerabilities

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

Other Languages

Related Guidelines

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

Bibliography

\[[Black 072007|AA. Bibliography#Black 07]\]
\[[CWE|AA. Bibliography#CWE]\] [CWE-226|http://cwe.mitre.org/data/definitions/226.html]: Sensitive Information Uncleared Before Release
\[CWE\] [CWE-244|http://cwe.mitre.org/data/definitions/244.html]: Failure to Clear Heap Memory Before Release ('Heap Inspection')
\[[Fortify 062006|AA. Bibliography#Fortify 06]\]
\[[Graff 032003|AA. Bibliography#Graf 03]\]
\[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\] Section 7.20.3, "Memory management functions"
\[[ISO/IEC PDTR 24772|AA. Bibliography#ISO/IEC PDTR 24772]\] "XZK Sensitive Information Uncleared Before Use"

...