CWE-1304 is about trust in saved state. The product performs a power save and restore operation but does not ensure the configuration state keeps its integrity between the start and end of the operation.
How it happens
To speed up wake-up, an IP block saves its current state, call it S, to persistent storage such as flash or always-on memory before power down. On restore it loads S back.
An attacker with access to that persistent storage can alter S. A changed S might modify privileges, disable protections, or damage the hardware. If the IP does not validate the saved state, the harmful configuration becomes active when power returns or the block becomes operational again.
What an attacker gains
MITRE rates the likelihood high. Consequences include gaining privileges or assuming identity, bypassing protection mechanisms, altering execution logic, and loss of confidentiality and integrity. The list also includes denial of service through instability, crash or resource consumption, an unexpected state, and reduced reliability, performance and maintainability.
How to find it
No detection methods are listed. Check these points:
- Find every place configuration is saved across power states and note who can write there.
- Corrupt the saved copy on purpose and watch what the block does on restore.
- Confirm the block refuses state that fails verification instead of using it anyway.
How to fix it
MITRE describes three designs. Pick the one that fits the architecture.
- Integrity check inside the IP. Before powering down, hash the configuration and store the hash in internal registers that never lose power. On restore, hash the saved configuration and compare. If they differ, the IP should not trust the configuration.
- Integrity check by a trusted agent outside the IP. The trusted agent hashes the configuration before power down and stores the hash in persistent storage. On restore, the IP asks the trusted agent to validate its current configuration. If the hash is invalid, the IP should not trust it.
- A protected environment. Before power down, a trusted agent saves the configuration in a location that only it is privileged to access. On restore, the trusted agent loads the saved state into the IP.
The common thread is that the thing doing the checking, or the place holding the reference, must be out of the attacker's reach.
Quick check
Why store the hash in registers that never lose power?
So the reference value cannot be altered by someone with access to the persistent storage that holds the configuration.
What should the IP do when the hash does not match?
Not trust the configuration.
