Sensitive data stored in reusable resources may be inadvertently leaked to a less privileged user or adversary if not properly cleared. Examples of reusable resources include:
- dynamically allocated memory
- statically allocated memory
- automatically allocated (stack) memory
- memory caches
- disk
- disk caches
The manner in which sensitive information can be properly cleared varies depending on the resource type and platform.
Non-Compliant Code Example: free()
| Wiki Markup |
|---|
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 cannot rely on memory being cleared during allocation either \[[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.
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.
...
| Code Block | ||
|---|---|---|
| ||
/* ... */
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
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).
...
| Wiki Markup |
|---|
NOTE: It is possible that the call to {{memset()}} in this example will be optimized out \[[MSC06-A. Be aware of insecure compiler optimization when dealing with sensitive data]\]. Be very careful to ensure that any sensitive data is actually cleared from memory. |
Non-Compliant 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.
...
| Wiki Markup |
|---|
The {{secret_size}} is tested to ensure that the integer multiplication ({{secret_size * 2}}) does not result in an integer overflow \[[INT32-C. Ensure that integer operations do not result in an 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.
...
| Wiki Markup |
|---|
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()}} \[[MEM07-A. Ensure that size arguments to calloc() do not result in an integer overflow]\]. |
Risk Assessment
| Wiki Markup |
|---|
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|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_. |
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MEM03-A | 2 (medium) | 1 (unlikely) | 3 (low) | P6 | L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[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" \[[NIST 06b|AA. C References#NIST 06b]\] |
...