CWE-1232 Base Incompleto

Improper Lock Behavior After Power State Transition

Definição

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 no mundo real

Real-world CVEs caused by CWE-1232

Ainda não há referências CVE públicas associadas a este CWE no catálogo da MITRE.

Como os atacantes a exploram

Trajeto do atacante passo a passo

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.

Exemplo de código vulnerável

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.

Vulnerável 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
  			 ...

Exemplo 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.

Seguro 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.

Lista de verificação de prevenção

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.

Sinais de deteção

How to detect CWE-1232

SAST High

Executar análise estática (SAST) na base de código à procura do padrão inseguro no fluxo de dados.

DAST Moderate

Executar testes dinâmicos de segurança de aplicações (DAST) contra o endpoint em execução.

Runtime Moderate

Monitorizar os registos em tempo de execução para traços de exceção invulgares, input malformado ou tentativas de contornar a autorização.

Code review Moderate

Revisão de código: sinalizar qualquer novo código que trate input desta superfície sem usar os ajudantes validados do framework.

Correção automática do Plexicus

O Plexicus deteta automaticamente o CWE-1232 e abre um PR de correção em menos de 60 segundos.

O Codex Remedium analisa cada commit, identifica esta fraqueza exata e entrega um pull request pronto para revisão com o patch. Sem tickets. Sem transferências.

Obter uma demonstração Experimente o Plexicus gratuitamente

Perguntas frequentes

Frequently asked questions

O que é o CWE-1232?

Qual a gravidade do CWE-1232?

A MITRE não publicou uma classificação de probabilidade de exploração para esta fraqueza. Trate-a como impacto médio até o seu modelo de ameaças provar o contrário.

Que linguagens ou plataformas são afetadas pelo CWE-1232?

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

Como posso prevenir o 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.

Como é que o Plexicus deteta e corrige o CWE-1232?

O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-1232 em cada commit. Quando é encontrada uma correspondência, o nosso agente Codex Remedium abre um PR de correção com o código corrigido, testes e um resumo de uma linha para o revisor.

Onde posso saber mais sobre o CWE-1232?

A MITRE publica a definição canónica em https://cwe.mitre.org/data/definitions/1232.html. Pode também consultar a documentação da OWASP e do NIST para orientações adjacentes.

Fraquezas relacionadas

Weaknesses related to CWE-1232

CWE-667 Pai

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 Irmão

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 Irmão

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 Irmão

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 Irmão

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 Irmão

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 Irmão

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 Irmão

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 Irmão

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

Pare de pagar por desenvolvedor.
Comece a fechar o ciclo.

O Plexicus é o ASPM nativo de IA que verifica, filtra, corrige, pentesta e explica — de forma autónoma. Programadores ilimitados, repos ilimitados, ações de IA de utilização justa. Nível gratuito real, €269/mo anual quando estiver pronto.

Começar grátis Reservar uma demo