CWE-1233 describes a product that uses a register lock bit, but does not ensure the lock bit prevents modification of the system registers or controls that perform changes to important hardware configuration. The lock exists. Its coverage has a hole.
It affects teams designing integrated circuits and hardware IP, and firmware teams who trust the locks.
How it happens
After a device resets, trusted firmware such as the BIOS or bootloader programs the configuration controls. There is then an expectation that the controls cannot be used for further modification. This is commonly implemented with a trusted lock bit that disables writes to a protected set of registers or address regions. The protection is meant to prevent changes to things like memory or memory protection unit configuration.
The flaw is incomplete coverage. If the lock bit does not effectively write-protect all the registers or controls that can change the protected configuration, an adversary may use software to reach those other controls and modify the protected hardware configuration anyway.
Two observed cases appear in the record:
- CVE-2018-9085: certain servers leave a write protection lock bit unset after boot, which potentially allows modification of parts of flash memory.
- CVE-2014-8273: a chain in which a chipset has a race condition between the moment an interrupt handler detects an attempt to write-enable the BIOS, in violation of the lock bit, and the moment the handler resets the write-enable.
The first is a lock never applied. The second is a lock applied too slowly.
What an attacker gains
MITRE lists an access control impact with the ability to modify memory. System configuration protected by the lock bit can be modified even when the lock is set.
How to find it
MITRE describes a manual analysis rated high:
- Set the lock bit.
- Attempt to modify the information the lock bit protects.
- If the information changes, implement a design fix and retest.
Also attempt to indirectly clear the lock bit or bypass it. List every register and control that can influence the protected configuration, not only the ones named in the lock's definition, and try each.
How to fix it
MITRE's mitigation covers design, implementation and testing. Review security lock bit protections for design inconsistency and common weaknesses. Test the lock programming flow and lock properties in pre-silicon and post-silicon testing.
Two checks from the observed cases are worth adding to the review:
- Verify the lock is actually set at the end of boot on shipped configurations.
- Check that the reaction to a violation, such as an interrupt handler, cannot be raced.
Quick check
What does missing lock bit protection look like?
The lock bit is set, but related registers or controls that can change the same configuration are not covered, so software modifies the configuration through them.
What went wrong in CVE-2018-9085?
Certain servers left a write protection lock bit unset after boot, which potentially allowed modification of parts of flash memory.
What is the manual test?
Set the lock bit, attempt to modify the protected information, and fix and retest if it changes. Also try indirect clears and bypasses.
