Sensitive data stored in reusable resources may be inadvertently leaked to a less privileged user or attacker 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.
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.
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.
In this noncompliant 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 *secret; /* Initialize secret to a null-terminated byte string, of less than SIZE_MAX chars */ size_t size = strlen(secret); char *new_secret; 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. Sanitization is commonly accomplished by clearing the allocated space (that is, filling the space with '\0'
characters).
char *secret; /* Initialize secret to a null-terminated byte string, of less than SIZE_MAX chars */ size_t size = strlen(secret); char *new_secret; /* Use calloc() to zero-out allocated space */ new_secret = (char *)calloc(size+1, sizeof(char)); if (!new_secret) { /* Handle error */ } strcpy(new_secret, secret); /* Process new_secret... */ /* Sanitize memory */ memset_s(new_secret, '\0', size); free(new_secret); new_secret = NULL;
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, do not wrap.)
See MSC06-C. Beware of compiler optimizations for a definition and discussion of using the memset_s()
function.
Noncompliant Code Example (realloc()
)
Reallocating memory using realloc()
can have the same problem as freeing memory. The realloc()
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 it may allow heap inspection, as described in Fortify Taxonomy: Software Security Errors [Fortify 2006] and NIST's Source Code Analysis Tool Functional Specification [Black 2007].
In this example, 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.
char *secret; /* Initialize secret */ size_t secret_size = strlen(secret); /* ... */ if (secret_size > SIZE_MAX/2) { /* Handle error condition */ } else { secret = (char *)realloc(secret, secret_size * 2); }
The secret_size
is tested to ensure that the integer multiplication (secret_size * 2
) does not result in an integer overflow. (See INT30-C. Ensure that unsigned integer operations do not wrap.)
Compliant Solution
A compliant program cannot rely on realloc()
because it is not possible to clear the memory before the call. Instead, a custom function must be used that operates similarly to realloc()
but sanitizes sensitive information as heap-based buffers are resized. Again, sanitization is done by overwriting the space to be deallocated with '\0'
characters.
char *secret; /* Initialize secret */ size_t secret_size = strlen(secret); char *temp_buff; /* ... */ if (secret_size > SIZE_MAX/2) { /* Handle error condition */ } /* calloc() initializes memory to zero */ temp_buff = (char *)calloc(secret_size * 2, sizeof(char)); if (temp_buff == NULL) { /* Handle error */ } memcpy(temp_buff, secret, secret_size); /* Sanitize the buffer */ memset((volatile char *)secret, '\0', secret_size); free(secret); secret = temp_buff; /* Install the resized buffer */ temp_buff = NULL;
The calloc()
function ensures that the newly allocated memory is also 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, do not wrap.)
Risk Assessment
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 2003] and Sun Security Bulletin #00122 [Sun 1993] 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
Tool | Version | Checker | Description |
---|---|---|---|
CodeSonar | 8.1p0 | (customization) | Users can add a custom check for use of realloc() . |
Compass/ROSE | Could detect possible violations of this rule by first flagging any usage of | ||
Helix QAC | 2024.2 | C5010 | |
LDRA tool suite | 9.7.1 | 44 S | Enhanced Enforcement |
Parasoft C/C++test | 2023.1 | CERT_C-MEM03-a | Sensitive data should be cleared before being deallocated |
Polyspace Bug Finder | R2024a | Checks for:
Rec. partially covered. | |
PVS-Studio | 7.33 | V1072 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
ISO/IEC TR 24772:2013 | Sensitive Information Uncleared Before Use [XZK] |
MITRE CWE | CWE-226, Sensitive information uncleared before release CWE-244, Failure to clear heap memory before release ("heap inspection") |
16 Comments
Robert Seacord
Need to add some discussion about declaring variables as volatile to prevent compilers from optimizing away memory wipes
Ben Tucker
David Wheeler discusses this issue here: http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/protect-secrets.html
Dave Aronson
This could be an issue on the stack too. More general principle: clear sensitive info out of all reusable resources (heap, stack, disk sectors, whiteboards, whatever) before returning it to reuse.
Robert Seacord
My initial reaction is to expand to include "memory" including heap, stack, data segment, etc.
I don't think we should discuss clearing disk memory, as I think this topic is very complex. For example, I found this quote on the subject: "There is only one real way to really ensure that data can not be accessed. This is to destroy the hard drive in a very hot fire and melt it."
I think whiteboards are outside of our scope. Once we start talking about mechanisms not defined by the language, the list becomes infinite.
There are a couple of topics referenced in the Wheeler article above that we may want to consider:
1. keeping memory form being paged to disk
2. disabling core dumps.
The problem with this rule (MEM03-A) is that it is a gateway to a bunch of other rules that talk about various security mechanisms which we have considered out of scope for this project. For example, we don't talk about encryption at all yet.
Dave Aronson
I didn't mean that we need to delve into the details of the other media. The main thing I meant was to acknowledge that it's a problem with all media. Maybe a list ("including but not limited to") of the most common types (such as those mentioned above, plus temp files) would help. No need to mention whiteboards. Post-It notes are Right Out. It could possibly be mentioned that encryption make the data meaningless to other programs, and leave the entire field of encryption as an exercise for the reader.
Robert Seacord
This rule may need to be consolidated with MSC06-C. Be aware of compiler optimization when dealing with sensitive data
David Keaton
I tried consolidating these and didn't like the result. It is worthwhile to go into detail on each subject separately rather than merge them into one very long recommendation.
Douglas A. Gwyn
One way to deal with agressive optimization is to use volatile qualification, which a conforming implementation must honor:
memset((volatile char *)new_secret, '\0', size);
Yozo TODA
I'm not completely sure the meaning of "regenerative case" in
Can we rewrite this to the following?
David Svoboda
I'm not sure what "regenerative case" means either. Rewritten.
Yozo TODA
thanks! very understandable for me now (-:
and I separated paragraphs.
Andrey Neyvanov
At the first Compliant solution the wrong check is not fixed:
if
(size == SIZE_MAX) {
/* Handle error */
}
if
(size >= SIZE_MAX) {
/* Handle error */
}
Aaron Ballman
SIZE_MAX
is the largest value asize_t
can hold. Sincesize
is declared as asize_t
, there are no values larger thanSIZE_MAX
that can be stored within the variable, and so==
is a correct implementation. Using>=
would also be correct, but misleading (and less efficient), since the value could never satisfy the>
.Andrey Neyvanov
If SIZE_MAX
is the largest value asize_t
can hold then it will be hard (impossible) to allocate this chunk of memory.Matthew Wilcox
size_t may be 16-bit. You can imagine a segmented architecture where no object may be larger than 65535 bytes, and thus defining SIZE_MAX to 65535 is correct. This would be permitted by the C11 standard. However, I still don't think the example is correct; strlen is not guaranteed to return SIZE_MAX on an object which does not contain a zero byte, and in any case, there's nothing wrong with having a 65535-byte long secret. What the author is trying to guard against is integer overflow in the next line where they do size + 1, which would overflow to 0; they would call malloc(0) and then write to ... well, it's not specified by C11 what malloc returns if you ask it to allocate 0 bytes. So it might allocate a full 64k segment, but more likely it would return NULL or it might return a non-NULL-value-which-isn't-valid, or it might return a pointer to the minimum-size-object that malloc supports (typically 1-8 bytes). All of the last three would lead to bad behaviour, either crashes or heap corruption.
I would avoid this problem altogether in the example and define a SECRET_MAX. I would also use strnlen, which I know isn't in C11, but is defined by POSIX-2008 and implemented by all good vendors (one can define one's own strnlen() in terms of memchr() if one is afflicted by having a poor vendor).
David Svoboda
Matthew's analysis is correct. However, the whole discussion of string lengths and malloc(0) is tangential to this recommendation. See MEM04-C. Beware of zero-length allocations and INT30-C. Ensure that unsigned integer operations do not wrap for more relavent details. So I recoded both the code examples to use a SECRET_MAX limit, as Matthew suggested.