CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.
View on MITREExtended Description
Integrated circuits and hardware intellectual properties (IPs) might provide device configuration controls that need to be programmed after device power reset by a trusted firmware or software module, commonly set by BIOS/bootloader. After reset, there can be an expectation that the controls cannot be used to perform any further modification. This behavior is commonly implemented using a trusted lock bit, which can be set to disable writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). However, if the lock bit does not effectively write-protect all system registers or controls that could modify the protected system configuration, then an adversary may be able to use software to access the registers/controls and modify the protected hardware configuration.
Technical Details
- Structure
- Simple
Applicable To
Security Consequences
Scope
Impact
System Configuration protected by the lock bit can be modified even when the lock is set.
Mitigation Strategies
Phase
Description
Security lock bit protections must be reviewed for design inconsistency and common weaknesses. Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.
Detection Methods
Method
Manual AnalysisDescription
Set the lock bit. Attempt to modify the information protected by the lock bit. If the information is changed, implement a design fix. Retest. Also, attempt to indirectly clear the lock bit or bypass it.
Effectiveness
HighCode Examples & CVEs
Demonstrative Examples
Consider the example design below for a digital thermal sensor that detects overheating of the silicon and triggers system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by the firmware.
In this example note that only the CRITICAL_TEMP_LIMIT register is protected by the TEMP_SENSOR_LOCK bit, while the security design intent is to protect any modification of the critical temperature detection and response. The response of the system, if the system heats to a critical temperature, is controlled by TEMP_HW_SHUTDOWN bit [1], which is not lockable. Also, the TEMP_SENSOR_CALIB register is not protected by the lock bit. By modifying the temperature sensor calibration, the conversion of the sensor data to a degree centigrade can be changed, such that the current temperature will never be detected to exceed critical temperature value programmed by the protected lock. Similarly, by modifying the TEMP_HW_SHUTDOWN.Enable bit, the system response detection of the current temperature exceeding critical temperature can be disabled.
Consider the example design below for a digital thermal sensor that detects overheating of the silicon and triggers system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by the firmware.
In this example note that only the CRITICAL_TEMP_LIMIT register is protected by the TEMP_SENSOR_LOCK bit, while the security design intent is to protect any modification of the critical temperature detection and response. The response of the system, if the system heats to a critical temperature, is controlled by TEMP_HW_SHUTDOWN bit [1], which is not lockable. Also, the TEMP_SENSOR_CALIB register is not protected by the lock bit. By modifying the temperature sensor calibration, the conversion of the sensor data to a degree centigrade can be changed, such that the current temperature will never be detected to exceed critical temperature value programmed by the protected lock. Similarly, by modifying the TEMP_HW_SHUTDOWN.Enable bit, the system response detection of the current temperature exceeding critical temperature can be disabled.
Observed CVE Examples (2)
Certain servers leave a write protection lock bit unset after boot, potentially allowing modification of parts of flash memory.
View DetailsChain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
View DetailsCWE Relationships
No relationship information available for this CWE.
Frequently Asked Questions
What is CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection?+
CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration. Integrated circuits and hardware intellectual properties (IPs) might provide device configuration controls that need to be programmed after device power reset by a trusted firmware or software module, commonly set by BIOS/bootloader. After reset, there can be an expectation that the controls cannot be used to perform any further modification. This behavior is commonly implemented using a trusted lock bit, which can be set to disable writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). However, if the lock bit does not effectively write-protect all system registers or controls that could modify the protected system configuration, then an adversary may be able to use software to access the registers/controls and modify the protected hardware configuration.
What are the security consequences of Security-Sensitive Hardware Controls with Missing Lock Bit Protection?+
If exploited, CWE-1233 (Security-Sensitive Hardware Controls with Missing Lock Bit Protection) it can compromise Access Control, leading to outcomes such as Modify Memory.
How do you prevent or mitigate Security-Sensitive Hardware Controls with Missing Lock Bit Protection?+
Recommended mitigations for CWE-1233 include: Security lock bit protections must be reviewed for design inconsistency and common weaknesses. Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.
How is Security-Sensitive Hardware Controls with Missing Lock Bit Protection detected?+
CWE-1233 can be detected using Manual Analysis. Combining automated tooling with manual review typically yields the best coverage.
Which programming languages are affected by Security-Sensitive Hardware Controls with Missing Lock Bit Protection?+
CWE-1233 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
What are real-world examples of Security-Sensitive Hardware Controls with Missing Lock Bit Protection?+
MITRE documents real CVEs mapped to CWE-1233, including CVE-2018-9085 and CVE-2014-8273. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
What is the difference between a CWE and a CVE?+
A CWE (Common Weakness Enumeration) like CWE-1233 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.