Versions Compared

Key

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

...

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 of compiler optimization when dealing with sensitive data for a definition and discussion of using the memset_s() function.

...

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 2006] and NIST's Source Code Analysis Tool Functional Specification [Black 2007]. 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.

...

The secret_size is tested to ensure that the integer multiplication (secret_size * 2) does not result in an integer overflow. (See INT32-C. Ensure that operations on signed integers do not result in overflow.)

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, this is done by overwriting the space to be deallocated with '\0' characters.

...

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

...

Klocwork_V

Tool

Version

Checker

Description

Klocwork

Include Page

Klocwork_V

SV.USAGERULES.UNINTENDED_COPY

 

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

Include Page
Klocwork_V
Klocwork_V

SV.USAGERULES.UNINTENDED_COPY

 

PRQA QA-C
Include Page
PRQA_V
PRQA_V
warncall for reallocPartially implemented

...

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

Related Guidelines

...

...

...

Sensitive information uncleared before release

...


...

...

...

, Failure to clear heap memory before release ("heap inspection")

...

ISO/IEC TR 24772 "XZK Sensitive information uncleared before use"

Bibliography

...