Page History

Sensitive data stored in reusable resources may be inadvertently leaked to a less privileged user or adversary attacker if not properly cleared. Examples of reusable resources include

• dynamically Dynamically allocated memory
• statically Statically allocated memory
• automatically Automatically allocated (stack) memory
• memory Memory caches
• diskDisk
• 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 (see 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.

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;

/* initializeInitialize secret to a null-terminated byte string, 
   of less than SIZE_MAX chars */

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

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. This Sanitization is commonly accomplished by clearing the allocated space (that is, filling the space with '\0' characters).

char *secret;

/* initializeInitialize secret to a null-terminated byte string, 
   of less than SIZE_MAX chars */

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

/* use 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... */

/* sanitizeSanitize memory  */
memset((volatile char *)_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 See MEM07-C. Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t).

NOTE: It is possible that the call to memset() in this example will be optimized out, although casting new secret as a volatile character should prevent this (see MSC06-C. Ensure that sensitive data is not written out to disk). Be very careful to ensure that any sensitive data is actually cleared from memory.

Noncompliant Code Example: realloc()

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. 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 MarkupUsing {{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 06|AA. C References#Fortify 06]\] and 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 _ \[[NIST 06b|AA. C References#NIST 06b]\]. 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;

/* initializeInitialize secret */

size_t secret_size = strlen(secret);
/* ... */
if (secret_size > SIZE_MAX/2) {
   /* handleHandle 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 INT32See INT30-C. Ensure that unsigned integer operations on signed integers do not result in overflowwrap.).

Compliant Solution

A compliant program cannot rely on realloc() because it is not possible to clear the memory prior to memory before the call. Instead, a custom function must be used that operates similar similarly to realloc() but sanitizes sensitive information as heap-based buffers are resized. Again, this sanitization is done by overwriting the space to be deallocated with '\0' characters.

char *secret;

/* initializeInitialize secret */

size_t secret_size = strlen(secret);
char *temp_buff;
/* ... */
if (secret_size > SIZE_MAX/2) {
   /* handleHandle 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);

/* sanitizeSanitize the buffer */
memset((volatile char *)secret, '\0', secret_size);

free(secret);
secret = temp_buff; /* installInstall the resized buffer */
temp_buff = NULL;

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

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 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_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

Medium

unlikely

Unlikely

high

High

P2

L3

Automated Detection

...

...

...

...

...

...

...

...

Related Vulnerabilities

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

References

\[[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"
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 226|http://cwe.mitre.org/data/definitions/226.html], "Sensitive Information Uncleared Before Release," [CWE ID 244|http://cwe.mitre.org/data/definitions/244.html], and "Failure to Clear Heap Memory Before Release"
\[[NIST 06b|AA. C References#NIST 06b]\]

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedImage Removed      08. Memory Management (MEM)       MEM04-C. Do not perform zero length allocations