Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 functions 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.

Code Block
bgColor#FFcccc
langc
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;

...

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).

Code Block
bgColor#ccccff
langc
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_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. Be aware Beware of compiler optimization when dealing with sensitive dataoptimizations for a definition and discussion of using the memset_s() function.

...

Reallocating memory using realloc() can have the same problem as freeing memory. The realloc() function de-allocates 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]. When

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.

Code Block
bgColor#FFcccc
langc
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);
}

...

Code Block
bgColor#ccccff
langc
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;

...

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

Medium

unlikely

Unlikely

high

High

P2

L3

Automated Detection

Tool

Version

Checker

Description

CodeSonar
Include Page
CodeSonar_V
CodeSonar_V
(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 realloc(). Also, it could flag any usage of free that is not preceded by code to clear out the preceding memory, using memset. This heuristic is imperfect because it flags all possible data leaks, not just leaks of "sensitive" data, because ROSE cannot tell which data is sensitive

Klocwork
Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C5010
LDRA tool suite
Include Page
Klocwork
LDRA_V
Klocwork
LDRA_V

SV.USAGERULES.UNINTENDED_COPY

 

PRQA QA-C Include PagePRQA_VPRQA_Vwarncall for reallocPartially implemented
44 SEnhanced Enforcement
Parasoft C/C++test

Include Page
Parasoft_V
Parasoft_V

CERT_C-MEM03-aSensitive data should be cleared before being deallocated
Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rec. MEM03-C


Checks for:

  • Sensitive heap memory not cleared before release
  • Uncleared sensitive data in stack

Rec. partially covered.

PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V1072

Related Vulnerabilities

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

Related Guidelines

CERT C++ Secure Coding StandardMEM03-CPP. Clear sensitive information stored in returned reusable resources
ISO/IEC TR 24772:2013Sensitive Information Uncleared Before Use [XZK]
MITRE CWECWE-226, Sensitive information uncleared before release
CWE-244, Failure to clear heap memory before release ("heap inspection")

Bibliography

...


...

Image Modified Image Modified Image Modified