CWE-14 Detail

Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."

This compiler optimization error occurs when:

1. Secret data are stored in memory.
2. The secret data are scrubbed from memory by overwriting its contents.
3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.

Modes Of Introduction

Implementation
Build and Compilation

Applicable Platforms

Language

Name: C (Undetermined)
Name: C++ (Undetermined)

Common Consequences

Potential Mitigations

Phases : Implementation
Store the sensitive data in a "volatile" memory location if available.
Phases : Build and Compilation
If possible, configure your compiler so that it does not remove dead stores.
Phases : Architecture and Design
Where possible, encrypt sensitive data that are used by a software system.

Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

Vulnerability Mapping Notes

Justification : This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

REF-6

Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, Gary McGraw.
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf

REF-7

Writing Secure Code
Michael Howard, David LeBlanc.
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223

REF-124

When scrubbing secrets in memory doesn't work
Michael Howard.
http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html

REF-125

Some Bad News and Some Good News
Michael Howard.
https://learn.microsoft.com/en-us/previous-versions/ms972826(v=msdn.10)

REF-126

GNU GCC: Optimizer Removes Code Necessary for Security
Joseph Wagner.
https://seclists.org/bugtraq/2002/Nov/266

Submission

Modifications