logo

Sensitive Information Uncleared Before Debug/Power State Transition

Stable Base
Structure: Simple
Description

The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.

Extended Description

A device or system frequently employs many power and sleep states during its normal operation (e.g., normal power, additional power, low power, hibernate, deep sleep, etc.). A device also may be operating within a debug condition. State transitions can happen from one power or debug state to another. If there is information available in the previous state which should not be available in the next state and is not properly removed before the transition into the next state, sensitive information may leak from the system.

Common Consequences 1
Scope: ConfidentialityIntegrityAvailabilityAccess ControlAccountabilityAuthenticationAuthorizationNon-Repudiation

Impact: Read MemoryRead Application Data

Sensitive information may be used to unlock additional capabilities of the device and take advantage of hidden functionalities which could be used to compromise device security.
Detection Methods 1
Manual AnalysisHigh
Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the device needs to be fixed. Note that this test can likely be automated.
Potential Mitigations 1
Phase: Architecture and DesignImplementation
During state transitions, information not needed in the next state should be removed before the transition to the next state.
Demonstrative Examples 1

ID : DX-147

This example shows how an attacker can take advantage of an incorrect state transition.
Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

Code Example:

Bad
Other

During the transition from A to B, the device does not scrub the memory.

After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

Code Example:

Good
Other

For transition from state A to state B, remove information which should not be available once the transition is complete.
Observed Examples 1
CVE-2020-12926Product software does not set a flag as per TPM specifications, thereby preventing a failed authorization attempt from being recorded after a loss of power.
References 1
Understanding the Security of ARM Debugging Features
Zhenyu Ning and Fengwei Zhang
2019 IEEE Symposium on Security and Privacy (SP)
22-05-2019
https://www.computer.org/csdl/proceedings-article/sp/2019/666000a602/1dlwieBPZ2o(2025-08-04)
ID: REF-1220
Applicable Platforms
Languages:
VHDL : UndeterminedVerilog : UndeterminedHardware Description Language : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Related Attack Patterns
Functional Areas
  1. Power
Related Weaknesses
ChildOf: Sensitive Information in Resource Not Removed Before Reuse (CWE-226)
CanPrecede: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)