Détail du CWE-1330

CWE-1330

Remanent Data Readable after Memory Erase
Draft
2020-12-10
00h00 +00:00
2023-06-29
00h00 +00:00
Notifications pour un CWE
Restez informé de toutes modifications pour un CWE spécifique.
Gestion des notifications

Nom: Remanent Data Readable after Memory Erase

Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.

Description du CWE

Data remanence occurs when stored, memory content is not fully lost after a memory-clear or -erase operation. Confidential memory contents can still be readable through data remanence in the hardware.

Data remanence can occur because of performance optimization or memory organization during 'clear' or 'erase' operations, like a design that allows the memory-organization metadata (e.g., file pointers) to be erased without erasing the actual memory content. To protect against this weakness, memory devices will often support different commands for optimized memory erase and explicit secure erase.

Data remanence can also happen because of the physical properties of memory circuits in use. For example, static, random-access-memory (SRAM) and dynamic, random-access-memory (DRAM) data retention is based on the charge retained in the memory cell, which depends on factors such as power supply, refresh rates, and temperature.

Other than explicit erase commands, self-encrypting, secure-memory devices can also support secure erase through cryptographic erase commands. In such designs, only the decryption keys for encrypted data stored on the device are erased. That is, the stored data are always remnant in the media after a cryptographic erase. However, only the encrypted data can be extracted. Thus, protection against data recovery in such designs relies on the strength of the encryption algorithm.

Informations générales

Modes d'introduction

Architecture and Design
Implementation

Plateformes applicables

Langue

Class: Not Language-Specific (Undetermined)

Systèmes d’exploitation

Class: Not OS-Specific (Undetermined)

Architectures

Class: Not Architecture-Specific (Undetermined)

Technologies

Name: Security Hardware (Undetermined)
Class: Not Technology-Specific (Undetermined)

Conséquences courantes

Portée Impact Probabilité
ConfidentialityModify Memory, Read Memory

Note: Confidential data are readable to untrusted agent.

Exemples observés

Références Description

CVE-2019-8575

Firmware Data Deletion Vulnerability in which a base station factory reset might not delete all user information. The impact of this enables a new owner of a used device that has been "factory-default reset" with a vulnerable firmware version can still retrieve, at least, the previous owner's wireless network name, and the previous owner's wireless security (such as WPA2) key. This issue was addressed with improved, data deletion.

Mesures d’atténuation potentielles

Phases : Architecture and Design
  • Support for secure-erase commands that apply multiple cycles of overwriting memory with known patterns and of erasing actual content.
  • Support for cryptographic erase in self-encrypting, memory devices.
  • External, physical tools to erase memory such as ultraviolet-rays-based erase of Electrically erasable, programmable, read-only memory (EEPROM).
  • Physical destruction of media device. This is done for repurposed or scrapped devices that are no longer in use.

Méthodes de détection

Architecture or Design Review

  • Testing of memory-device contents after clearing or erase commands.
  • Dynamic analysis of memory contents during device operation to detect specific, confidential assets.
  • Architecture and design analysis of memory clear and erase operations.

Dynamic Analysis with Manual Results Interpretation

  • Testing of memory-device contents after clearing or erase commands.
  • Dynamic analysis of memory contents during device operation to detect specific, confidential assets.
  • Architecture and design analysis of memory clear and erase operations.

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.

Modèles d'attaque associés

CAPEC-ID Nom du modèle d'attaque
CAPEC-150 Collect Data from Common Resource Locations
An adversary exploits well-known locations for resources for the purposes of undermining the security of the target. In many, if not most systems, files and resources are organized in a default tree structure. This can be useful for adversaries because they often know where to look for resources or files that are necessary for attacks. Even when the precise location of a targeted resource may not be known, naming conventions may indicate a small area of the target machine's file tree where the resources are typically located. For example, configuration files are normally stored in the /etc director on Unix systems. Adversaries can take advantage of this to commit other types of attacks.
CAPEC-37 Retrieve Embedded Sensitive Data
An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.
CAPEC-545 Pull Data from System Resources
An adversary who is authorized or has the ability to search known system resources, does so with the intention of gathering useful information. System resources include files, memory, and other aspects of the target system. In this pattern of attack, the adversary does not necessarily know what they are going to find when they start pulling data. This is different than CAPEC-150 where the adversary knows what they are looking for due to the common location.

Références

REF-1154

NIST Special Publication 800-88 Revision 1: Guidelines for Media Sanitization
National Institute of Standards and Technology.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf

Soumission

Nom Organisation Date Date de publication Version
Hareesh Khattri, Arun Kanuparthi, Parbati K. Manna Intel Corporation 2020-06-10 +00:00 2020-12-10 +00:00 4.3

Modifications

Nom Organisation Date Commentaire
CWE Content Team MITRE 2022-04-28 +00:00 updated Applicable_Platforms
CWE Content Team MITRE 2022-06-28 +00:00 updated Applicable_Platforms
CWE Content Team MITRE 2023-04-27 +00:00 updated Relationships
CWE Content Team MITRE 2023-06-29 +00:00 updated Mapping_Notes