CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.5)  
ID

CWE-1330: Remanent Data Readable after Memory Erase

Weakness ID: 1330
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.
+ Extended Description

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.

+ Relationships
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1301Insufficient or Incomplete Data Removal within Hardware Component
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1301Insufficient or Incomplete Data Removal within Hardware Component
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Security IP (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Modify Memory; Read Memory

Confidential data are readable to untrusted agent.
+ Demonstrative Examples

Example 1

Consider a device that uses flash memory for non-volatile-data storage. To optimize flash-access performance or reliable-flash lifetime, the device might limit the number of flash writes/erases by maintaining some state in internal SRAM and only committing changes to flash memory periodically.

The device also supports user reset to factory defaults with the expectation that all personal information is erased from the device after this operation. On factory reset, user files are erased using explicit, erase commands supported by the flash device.

In the given, system design, the flash-file system can support performance-optimized erase such that only the file metadata are erased and not the content. If this optimized erase is used for files containing user data during factory-reset flow, then device, flash memory can contain remanent data from these files.

On device-factory reset, the implementation might not erase these copies, since the file organization has changed and the flash file system does not have the metadata to track all previous copies.

A flash-memory region that is used by a flash-file system should be fully erased as part of the factory-reset flow. This should include secure-erase flow for the flash media such as overwriting patterns multiple times followed by erase.

+ Observed Examples
ReferenceDescription
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.
+ Potential Mitigations

Phase: Architecture and Design

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

Architecture or Design Review

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

Dynamic Analysis with Manual Results Interpretation

  1. Testing of memory-device contents after clearing or erase commands.
  2. Dynamic analysis of memory contents during device operation to detect specific, confidential assets.
  3. Architecture and design analysis of memory clear and erase operations.
+ References
[REF-1154] National Institute of Standards and Technology. "NIST Special Publication 800-88 Revision 1: Guidelines for Media Sanitization". 2014-12. <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-06-10Hareesh Khattri, Arun Kanuparthi, Parbati K. MannaIntel Corporation
More information is available — Please select a different filter.
Page Last Updated: July 20, 2021