CWE-1234: Hardware Internal or Debug Modes Allow Override… | Glexia
CWE-1234 (Hardware Internal or Debug Modes Allow Override of Locks) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE…
Glexia's Take · Automated analysis
CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks
Hardware Internal or Debug Modes Allow Override of Locks represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Access Control: Bypass Protection Mechanism: Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.
Developer Pattern
CWE-1234 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-1234, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks
System configuration protection may be bypassed during debug mode.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1.However, it also allows override of the lock protection when scan_mode or debug_unlocked modes are active. If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock protection may be bypassed.
- The following example code [REF-1375] is taken from the register lock security peripheral of the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These reglk_mem registers are reset when the hardware powers up and configured during boot up. Malicious users, even with kernel-level software privilege, do not get access to the sensitive contents that are locked down. Hence, the security of the entire system can potentially be compromised if the register lock configurations are corrupted or if the register locks are disabled. The example code [REF-1375] illustrates an instance of a vulnerable implementation of register locks in the SoC. In this flawed implementation [REF-1375], the reglk_mem registers are also being reset when the system enters debug mode (indicated by the jtag_unlock signal). Consequently, users can simply put the processor in debug mode to access sensitive contents that are supposed to be protected by the register lock feature.,This can be mitigated by excluding debug mode signals from the reset logic of security-critical register locks as demonstrated in the following code snippet [REF-1376].
Remediation
- Architecture and Design,Implementation,Testing:
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.