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 marks that memory for deallocation. Once deallocated, the block of 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.
This scenario can lead to information leakage; for instance, as is described in Rule: MEM33-C. Do not assume memory allocation routines initialize memory. 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 1
In this noncompliant example, sensitive information in stored in the buffer dynamically allocated memory referenced by secret
is copied to the dynamically allocated buffer, new_secret
, which is then processed and eventually marked for deallocation with deallocated by a call to free()
. However, the contents of new_secret
may remain in heap memory after being marked for deallocation. Furthermore, if this memory is recycled by the heap manager, 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 exposed to another, unintended section of the program, or another program entirelyunintentionally leaked.
Code Block | ||||
---|---|---|---|---|
| ||||
... char *new_secret; size_t size = strlen(secret); if (size ==/* Initialize secret to a null-terminated byte string, of less than SIZE_MAX) { /* Handle Error */ } chars */ size_t size = strlen(secret); char *new_secret; new_secret = (char *)malloc(size+1); if (!new_secret) { /* Handle Errorerror */ } 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 it is marked for deallocation. Below, this is done by filling the allocated space with {{ before being freed. Sanitization is commonly accomplished by clearing the allocated space (that is, filling the space with Wiki Markup '\0'
}} characters. Note that {{calloc()}} is also used to zero-out newly allocated memory. Note that 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 | MEM37-C. Ensure that size arguments to calloc() do not result in an integer overflow]\]..
Code Block | ||||
---|---|---|---|---|
| ||||
char *secret;
/* Initialize secret to a null-terminated byte string,
of less than SIZE_MAX chars */
| ||||
Code Block | ||||
| ||||
... char *new_secret; size_t size = strlen(secret); if (size == SIZE_MAX) { /* Handle Error */ } char *new_secret; /* Use calloc() to zero-out allocated space */ new_secret = (char *)calloc(size+1, sizeof(char)); /* use calloc() to zero-out allocated space */ if (!new_secret) { /* Handle Errorerror */ } strcpy(new_secret, secret); /* Process new_secret... */ /* Sanitize memory */ memset_s(new_secret, '\0', size); /* sanitize memory */ 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
Non-Compliant Code Example 2
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|http://vulncat.fortifysoftware.com/2/HI.html]\] and NIST's Source Code Analysis Tool Functional Specification \[[SAMATE]\]. When {{realloc()}} is called it may allocate a new, larger block of memory, copy the contents, of {{secret}} to this new block, {{free()}} the original block, and assign the newly allocated block to {{secret}}. However, the contents of the original block may remain in heap memory after being marked for deallocation. Wiki Markup
Code Block | ||||
---|---|---|---|---|
| ||||
char *secret; /* Initialize secret */ size_t secret_size = strlen(secret); /* ... */ if (secret_size > SIZE_MAX/2) { /* Handle error condition */ } else { secret = (char *)realloc(secret, ,newsecret_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 Correcting this example requires the programmer to write a custom routine that operates similar to realloc()
, but sanitizes sensitive information as heap-based buffers are resized. First, a new, resized block of memory is allocated (note that calloc()
is used to ensure its contents are properly initialized). Second, the contents of secret
are copied to this new space. Next, the memory referred to by secret
is sanitized by overwriting its contents Again, sanitization is done by overwriting the space to be deallocated with '\0'
characters. Next, the memory referred to by secret
is then free()
'd. Finally, the newly allocated space is installed, taking care to remove all unneeded references to the new space.Note that this solution will truncate the contents of original buffer, secret
if the size of the resized buffer is smaller. This behavior is similar to how realloc()
handles resizing to a smaller block of memory.
Code Block | ||||
---|---|---|---|---|
| ||||
... temp_buffchar *secret; /* Initialize secret */ size_t secret_size = calloc(new_size,sizeof(char)); /* use calloc() to zero-out allocated space strlen(secret); char *temp_buff; /* ... */ if (tempsecret_buffsize == NULL> SIZE_MAX/2) { /* Handle error Errorcondition */ } if (/* calloc() initializes memory to zero */ temp_buff = (char *)calloc(secret_size > new_size) * 2, sizeof(char)); if (temp_buff == NULL) { /* mayHandle lead toerror truncation */ secret_size = new_size;} memcpy(temp_buff, secret , secret_size); /* Sanitize the buffer */ memset((volatile char *)secret, '\0', secret_size); /* sanitize the buffer */ free(secret); secret = temp_buff; /* installInstall 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
Failure to clear dynamic memory can result in leaked information.
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 |
---|
MEM33-C
2 (medium)
1 (unlikely)
3 (low)
P6
L2
References
MEM03-C | Medium | Unlikely | High | P2 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar |
| (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 |
| C5010 | |||||||
LDRA tool suite |
| 44 S | Enhanced Enforcement | ||||||
Parasoft C/C++test |
| CERT_C-MEM03-a | Sensitive data should be cleared before being deallocated | ||||||
Polyspace Bug Finder |
| Checks for:
Rec. partially covered. | |||||||
PVS-Studio |
| 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") |
Bibliography
...
http://vulncat.fortifysoftware.com/2/HI.html
http://samate.nist.gov/docs/SAMATE_source_code_analysis_tool_spec_09_15_06.pdf
MEM33-C. Do not assume memory allocation routines initialize memory