Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation

The product performs a power save/restore operation, but it does not ensure that the integrity of the configuration state is maintained and/or verified between the beginning and ending of the operation.


Description

Before powering down, the Intellectual Property (IP) saves current state (S) to persistent storage such as flash or always-on memory in order to optimize the restore operation. During this process, an attacker with access to the persistent storage may alter (S) to a configuration that could potentially modify privileges, disable protections, and/or cause damage to the hardware. If the IP does not validate the configuration state stored in persistent memory, upon regaining power or becoming operational again, the IP could be compromised through the activation of an unwanted/harmful configuration.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

The following pseudo code demonstrates the power save/restore workflow which may lead to weakness through a lack of validation of the config state after restore.

void save_config_state()
{

  void* cfg;

  cfg = get_config_state();
  save_config_state(cfg);

  go_to_sleep();

}

void restore_config_state()
{

  void* cfg;
  cfg = get_config_file();
  load_config_file(cfg);

}

The following pseudo-code is the proper workflow for the integrity checking mitigation:

void save_config_state()
{

  void* cfg;
  void* sha;

  cfg = get_config_state();
  save_config_state(cfg);

  // save hash(cfg) to trusted location
  sha = get_hash_of_config_state(cfg);
  save_hash(sha);

  go_to_sleep();

}

void restore_config_state()
{

  void* cfg;
  void* sha_1, sha_2;

  cfg = get_config_file();
  // restore hash of config from trusted memory
  sha_1 = get_persisted_sha_value();

  sha_2 = get_hash_of_config_state(cfg);
  if (sha_1 != sha_2)

    assert_error_and_halt();


  load_config_file(cfg);

}

It must be noted that in the previous example of good pseudo code, the memory (where the hash of the config state is stored) must be trustworthy while the hardware is between the power save and restore states.

See Also

Power, Clock, and Reset Concerns

Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses without Software Fault Patterns

CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...

Weaknesses Introduced During Design

This view (slice) lists weaknesses that can be introduced during design.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.