Détail du CWE-316

The product stores sensitive information in cleartext in memory.

The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the product crashes, or if the programmer does not properly clear the memory before freeing it.

It could be argued that such problems are usually only exploitable by those with administrator privileges. However, swapping could cause the memory to be written to disk and leave it accessible to physical attack afterwards. Core dump files might have insecure permissions or be stored in archive files that are accessible to untrusted people. Or, uncleared sensitive memory might be inadvertently exposed to attackers due to another weakness.

Modes d'introduction

Architecture and Design : OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.

Plateformes applicables

Langue

Class: Not Language-Specific (Undetermined)

Conséquences courantes

Exemples observés

Notes de cartographie des vulnérabilités

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.
Commentaire : 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.

NotesNotes

This could be a resultant weakness, e.g. if the compiler removes code that was intended to wipe memory.
Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).

Soumission

Modifications