Ejecuta análisis estático (SAST) sobre el código buscando el patrón inseguro en el flujo de datos.
CWE-1232 Base Incompleto
Improper Lock Behavior After Power State Transition
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…
Definición
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.
Impacto en el mundo real
Real-world CVEs caused by CWE-1232
Todavía no hay CVEs públicos enlazados a esta CWE en el catálogo de MITRE.
Cómo lo explotan los atacantes
Ruta del atacante paso a paso
- 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.
Ejemplo de código vulnerable
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.
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
... Ejemplo de código seguro
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.
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.
Lista de prevención
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.
Señales de detección
How to detect CWE-1232
Ejecuta pruebas dinámicas de seguridad de aplicaciones (DAST) contra el endpoint en vivo.
Vigila los logs en tiempo de ejecución para detectar trazas de excepción inusuales, entradas malformadas o intentos de bypass de autorización.
Revisión de código: marca cualquier código nuevo que maneje entrada desde esta superficie sin usar los helpers validados del framework.
Plexicus detecta automáticamente CWE-1232 y abre un PR de corrección en menos de 60 segundos.
Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.
Preguntas frecuentes ¿Qué es CWE-1232?
¿Qué gravedad tiene CWE-1232?
¿Qué lenguajes o plataformas se ven afectados por CWE-1232?
¿Cómo puedo prevenir CWE-1232?
¿Cómo detecta y corrige Plexicus CWE-1232?
¿Dónde puedo aprender más sobre CWE-1232?
Frequently asked questions
¿Qué es 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.
¿Qué gravedad tiene CWE-1232?
MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.
¿Qué lenguajes o plataformas se ven afectados por CWE-1232?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.
¿Cómo puedo prevenir 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.
¿Cómo detecta y corrige Plexicus CWE-1232?
El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-1232 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.
¿Dónde puedo aprender más sobre CWE-1232?
MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/1232.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.
Debilidades relacionadas
Weaknesses related to CWE-1232
CWE-667 Padre
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 Hermano
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 Hermano
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 Hermano
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 Hermano
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 Hermano
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 Hermano
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 Hermano
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 Hermano
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…
Recursos
Further reading
- MITRE — CWE-1232 oficial https://cwe.mitre.org/data/definitions/1232.html
- reglk_wrapper.sv https://github.com/HACK-EVENT/hackatdac21/blob/65d0ffdab7426da4509c98d62e163bcce642f651/piton/design/chip/tile/ariane/src/reglk/reglk_wrapper.sv#L39C1-L39C1
- Bad Code reglk_wrapper.sv https://github.com/HACK-EVENT/hackatdac21/blob/65d0ffdab7426da4509c98d62e163bcce642f651/piton/design/chip/tile/ariane/src/reglk/reglk_wrapper.sv#L78C1-L85C16
- Good Code reglk_wrapper.sv https://github.com/HACK-EVENT/hackatdac21/blob/5e2031fd3854bcc0b2ca11d13442542dd5ea98e0/piton/design/chip/tile/ariane/src/reglk/reglk_wrapper.sv#L83
Listo cuando tú lo estés
Deja de pagar por desarrollador.
Empieza a cerrar el bucle.
Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.