Page History

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 \[[MEM09-A. Do not assume memory allocation routines initialize memory]\].

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

new_secret = (char *)malloc(size+1);
if (!new_secret) {
  /* Handle Error */
}
strcpy(new_secret, secret);

/* Process new_secret... */

free(new_secret);
new_secret = NULL;

char *new_secret;
size_t size = strlen(secret);
if (size == SIZE_MAX) {
  /* Handle Error */
}
/* 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(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()}} \[[MEM07-A. 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 \[[MSC06-A. Be aware of compiler optimization when dealing with sensitive data]\].  Be very careful to ensure that any sensitive data is actually cleared from memory.

Using {{realloc()}} to resize dynamic memory may inadvertently expose sensitive information, or it may allow heap inspection as 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_ \[[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.

size_t secret_size;
/* ... */
if (secret_size > SIZE_MAX/2) {
   /* handle error condition */
}

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 \[[INT32-C. Ensure that operations on signed integers do not result in overflow]\].

size_t secret_size;
/* ... */
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(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 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 the arguments to calloc() when multiplied can be represented as a size_t]\].

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

\[[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]\]