CWE-14: Compiler Removal of Code to Clear Buffers

Description

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:

Potential Impact

Confidentiality, Access Control

Read Memory, Bypass Protection Mechanism

Demonstrative Examples

The following code reads a password from the
              user, uses the password to connect to a back-end
              mainframe, and then attempts to scrub the password from
              memory using memset().

Bad

void GetData(char *MFAddr) {
				 
				   char pwd[64];
				   if (GetPasswordFromUser(pwd, sizeof(pwd))) {
				   
					 if (ConnectToMainframe(MFAddr, pwd)) {
					 
					   // Interaction with mainframe
					 
					 }
				   
				   }
				   memset(pwd, 0, sizeof(pwd));
                 
				 }

The code in the example will behave
               correctly if it is executed verbatim, but if the code
               is compiled using an optimizing compiler, then the call to
               memset() might be removed as a dead store, because the
               buffer pwd is not used after its value is overwritten.
               Because the buffer pwd contains a sensitive
               value, the application may be vulnerable to attack if
               the data are left memory resident. If attackers are
               able to access the correct region of memory, they may
               use the recovered password to gain control of the
               system.

It is common practice to overwrite sensitive
               data manipulated in memory, such as passwords or
               cryptographic keys, in order to prevent attackers from
               learning system secrets. However, with the advent of
               optimizing compilers, programs do not always behave as
               their source code alone would suggest. In the example,
               the compiler interprets the call to memset() as dead
               code because the memory being written to is not
               subsequently used, despite the fact that there is
               clearly a security motivation for the operation to
               occur. The problem here is that many compilers, and in
               fact many programming languages, do not take this and
               other security concerns into consideration in their
               efforts to improve efficiency.

Attackers typically exploit this type of
               vulnerability by using a core dump or runtime mechanism
               to access the memory used by a particular application
               and recover the secret information. Once an attacker
               has access to the secret information, it is relatively
               straightforward to further exploit the system and
               possibly compromise other resources with which the
               application interacts.

Mitigations & Prevention

Implementation

Store the sensitive data in a "volatile" memory location if available.

Build and Compilation

If possible, configure your compiler so that it does not remove dead stores.

Architecture and Design

Where possible, encrypt sensitive data that are used by a software system.

Detection Methods

Black Box Limited — 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 wh
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.

Taxonomy Mappings

7 Pernicious Kingdoms: — Insecure Compiler Optimization
PLOVER: — Sensitive memory uncleared by compiler optimization
OWASP Top Ten 2004: A8 — Insecure Storage
CERT C Secure Coding: MSC06-C — Be aware of compiler optimization when dealing with sensitive data
Software Fault Patterns: SFP23 — Exposed Data

Frequently Asked Questions

What is CWE-14?

CWE-14 (Compiler Removal of Code to Clear Buffers) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. 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."

How can CWE-14 be exploited?

Attackers can exploit CWE-14 (Compiler Removal of Code to Clear Buffers) to read memory, bypass protection mechanism. This weakness is typically introduced during the Implementation, Build and Compilation phase of software development.

How do I prevent CWE-14?

Key mitigations include: Store the sensitive data in a "volatile" memory location if available.

What is the severity of CWE-14?

CWE-14 is classified as a Variant-level weakness (Low-Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.