CWE-1232 Base Incomplet

Improper Lock Behavior After Power State Transition

Définition

What is CWE-1232?

This vulnerability occurs when a hardware lock bit, designed to protect critical system configuration registers, is improperly reset or becomes programmable after a device transitions between power states, such as entering or waking from a low-power sleep mode. This allows the protected configuration to be altered after it should be permanently locked.

Many hardware systems use a programmable lock bit to secure configuration settings. A trusted agent like the BIOS or bootloader sets this bit after initial configuration, which should permanently prevent further writes to sensitive registers. However, if this lock is cleared or the protected registers are reset when the device wakes from a sleep state or undergoes another power transition, the intended security mechanism fails. This flaw exposes the system to post-boot attacks where malicious software can alter low-level device settings that control memory, peripherals, or security features. Developers must verify that lock bit states and protected register values are preserved consistently across all designed power state transitions, including sleep, hibernation, and warm resets, to ensure runtime integrity.

Impact réel

Real-world CVEs caused by CWE-1232

Aucune référence CVE publique n'est liée à ce CWE dans le catalogue MITRE pour le moment.

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

1
Consider the memory configuration settings of a system that uses DDR3 DRAM memory. Protecting the DRAM memory configuration from modification by software is required to ensure that system memory access control protections cannot be bypassed. This can be done by using lock bit protection that locks all of the memory configuration registers. The memory configuration lock can be set by the BIOS during the boot process. If such a system also supports a rapid power on mode like hibernate, the DRAM data must be saved to a disk before power is removed and restored back to the DRAM once the system powers back up and before the OS resumes operation after returning from hibernate.
2
To support the hibernate transition back to the operating state, the DRAM memory configuration must be reprogrammed even though it was locked previously. As the hibernate resume does a partial reboot, the memory configuration could be altered before the memory lock is set. Functionally the hibernate resume flow requires a bypass of the lock-based protection. The memory configuration must be securely stored and restored by trusted system firmware. Lock settings and system configuration must be restored to the same state it was in before the device entered into the hibernate mode.
3
The example code below is taken from the register lock module (reglk_wrapper) of the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Upon powering on, most of the silicon registers are initially unlocked. However, critical resources must be configured and locked by setting the lock bit in a register. In this module, a set of six memory-mapped I/O registers (reglk_mem) is defined and maintained to control the access control of registers inside different peripherals in the SoC [REF-1432]. Each bit represents a register's read/write ability or sets of registers inside a peripheral. Setting improper lock values after system power transition or system rest would make a temporary window for the attackers to read unauthorized data, e.g., secret keys from the crypto engine, and write illegitimate data to critical registers, e.g., framework data. Furthermore, improper register lock values can also result in DoS attacks. In this faulty implementation, the locks are disabled, i.e., initialized to zero, at reset instead of setting them to their appropriate values [REF-1433]. Improperly initialized locks might allow unauthorized access to sensitive registers, compromising the system's security.
4
To resolve this issue, it is crucial to ensure that register locks are correctly initialized during the reset phase of the SoC. Correct initialization values should be established to maintain the system's integrity, security, and predictable behavior and allow for proper control of peripherals. The specifics of initializing register locks and their values depend on the SoC's design and the system's requirements; for example, access to all registers through the user privilege level should be locked at reset. To address the problem depicted in the bad code example [REF-1433], the default value for "reglk_mem" should be set to 32'hFFFFFFFF. This ensures that access to protected data is restricted during power state transition or after reset until the system state transition is complete and security procedures have properly configured the register locks.

Exemple de code vulnérable

Vulnerable Verilog

The example code below is taken from the register lock module (reglk_wrapper) of the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Upon powering on, most of the silicon registers are initially unlocked. However, critical resources must be configured and locked by setting the lock bit in a register. In this module, a set of six memory-mapped I/O registers (reglk_mem) is defined and maintained to control the access control of registers inside different peripherals in the SoC [REF-1432]. Each bit represents a register's read/write ability or sets of registers inside a peripheral. Setting improper lock values after system power transition or system rest would make a temporary window for the attackers to read unauthorized data, e.g., secret keys from the crypto engine, and write illegitimate data to critical registers, e.g., framework data. Furthermore, improper register lock values can also result in DoS attacks. In this faulty implementation, the locks are disabled, i.e., initialized to zero, at reset instead of setting them to their appropriate values [REF-1433]. Improperly initialized locks might allow unauthorized access to sensitive registers, compromising the system's security.

Vulnérable Verilog

module reglk_wrapper #(
 ...

```
   always @(posedge clk_i)
  	 begin
  		 if(~(rst_ni && ~jtag_unlock && ~rst_9))
  			 begin
  				 for (j=0; j < 6; j=j+1) begin
```
reglk_mem[j] <= 'h0;** 
  					 end
  				 end
  			 ...

Exemple de code sécurisé

Secure Verilog

To resolve this issue, it is crucial to ensure that register locks are correctly initialized during the reset phase of the SoC. Correct initialization values should be established to maintain the system's integrity, security, and predictable behavior and allow for proper control of peripherals. The specifics of initializing register locks and their values depend on the SoC's design and the system's requirements; for example, access to all registers through the user privilege level should be locked at reset. To address the problem depicted in the bad code example [REF-1433], the default value for "reglk_mem" should be set to 32'hFFFFFFFF. This ensures that access to protected data is restricted during power state transition or after reset until the system state transition is complete and security procedures have properly configured the register locks.

Sécurisé Verilog

module reglk_wrapper #(
 ...

```
   always @(posedge clk_i)
  	 begin
  		 if(~(rst_ni && ~jtag_unlock && ~rst_9))
  			 begin
  				 for (j=0; j < 6; j=j+1) begin
```
reglk_mem[j] <= 'hffffffff;** 
  					 end
  				 end
  			 ...

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Liste de contrôle de prévention

How to prevent CWE-1232

Architecture and Design / Implementation / Testing - Security Lock bit protections should be reviewed for behavior across supported power state transitions. - Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing including testing across power transitions.

Signaux de détection

How to detect CWE-1232

SAST High

Exécuter une analyse statique (SAST) sur le code source à la recherche du motif non sécurisé dans le flux de données.

DAST Moderate

Exécuter des tests de sécurité applicative dynamique (DAST) contre le point de terminaison en ligne.

Runtime Moderate

Surveiller les journaux runtime pour détecter des traces d'exception inhabituelles, des entrées malformées ou des tentatives de contournement d'autorisation.

Code review Moderate

Revue de code : signaler tout nouveau code qui traite les entrées de cette surface sans utiliser les helpers du framework validés.

Correction automatique Plexicus

Plexicus détecte automatiquement CWE-1232 et ouvre une PR de correction en moins de 60 secondes.

Codex Remedium analyse chaque commit, identifie cette faiblesse précise et livre une pull request prête à être relue avec le correctif. Pas de tickets. Pas de transferts.

Obtenir une démo Essayer Plexicus gratuitement

Questions fréquentes

Frequently asked questions

Qu'est-ce que CWE-1232 ?

Quelle est la gravité de CWE-1232 ?

MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.

Quels langages ou plateformes sont affectés par CWE-1232 ?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.

Comment puis-je prévenir CWE-1232 ?

- Security Lock bit protections should be reviewed for behavior across supported power state transitions. - Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing including testing across power transitions.

Comment Plexicus détecte et corrige CWE-1232 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-1232 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.

Où puis-je en savoir plus sur CWE-1232 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/1232.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Faiblesses associées

Weaknesses related to CWE-1232

CWE-667 Parent

Improper Locking

This vulnerability occurs when a program fails to correctly acquire or release a lock on a shared resource, such as a file, database…

CWE-1233 Frère

Security-Sensitive Hardware Controls with Missing Lock Bit Protection

This vulnerability occurs when a hardware device uses a lock bit to protect critical configuration registers, but the lock fails to…

CWE-1234 Frère

Hardware Internal or Debug Modes Allow Override of Locks

Hardware debug modes or internal states can bypass critical system lock protections, allowing unauthorized changes to device configuration.

CWE-412 Frère

Unrestricted Externally Accessible Lock

This vulnerability occurs when a system correctly checks for a lock's existence, but an unauthorized external actor can control or…

CWE-413 Frère

Improper Resource Locking

This vulnerability occurs when an application fails to properly lock a shared resource, such as a file or memory location, before…

CWE-414 Frère

Missing Lock Check

This vulnerability occurs when software fails to verify that a proper synchronization lock is active before accessing or modifying a…

CWE-609 Frère

Double-Checked Locking

Double-checked locking is an insufficient synchronization pattern where a program checks a resource's state, acquires a lock, and checks…

CWE-764 Frère

Multiple Locks of a Critical Resource

This vulnerability occurs when a critical resource, such as a file, data structure, or connection, is locked more times than the software…

CWE-765 Frère

Multiple Unlocks of a Critical Resource

This vulnerability occurs when a critical resource, like a lock or semaphore, is unlocked more times than it was locked, putting the…

Ressources

Arrêtez de payer par développeur.
Commencez à fermer la boucle.

Plexicus est l'ASPM natif IA qui scanne, filtre, corrige, penteste et explique — de façon autonome. Développeurs illimités, dépôts illimités, actions IA à usage équitable. Vrai niveau gratuit, €269/mo annuel quand vous êtes prêt.

Commencer gratuitement Réserver une démo