CWE-1272: Sensitive Information Uncleared Before… | Glexia
CWE-1272 (Sensitive Information Uncleared Before Debug/Power State Transition) weakness overview with consequences, detection methods, mitigations, related CVEs…
Glexia's Take · Automated analysis
CWE-1272: Sensitive Information Uncleared Before Debug/Power State Transition
Sensitive Information Uncleared Before Debug/Power State Transition represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Confidentiality Integrity Availability Access Control Accountability Authentication Authorization Non-Repudiation: Read Memory Read 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.
Developer Pattern
CWE-1272 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-1272, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-1272: Sensitive Information Uncleared Before Debug/Power State Transition
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.
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.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- 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. 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.
Remediation
- Architecture and Design Implementation: During state transitions, information not needed in the next state should be removed before the transition to the next state.
Detection
- Manual Analysis: 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.
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.