CWE-1231 describes a product that relies on a trusted lock bit to restrict access to registers, address regions or other resources, but does not stop the lock bit itself from being modified after it is set. It is a flaw for hardware and firmware teams, and it has software parallels.
How it happens
In integrated circuits and hardware IP cores, device configuration controls are programmed after power reset by trusted firmware or software, such as the BIOS or bootloader, and then locked against further changes. The lock bit is the mechanism. When set, it disables writes to a protected set of registers or address regions.
Design or coding errors in the lock bit protection may let software modify or clear the bit after it has been set. Attackers might then be able to unlock the system and the features the bit was meant to protect.
The record gives one observed case: CVE-2017-6283, where a chip reset cleared critical read and write lock permissions for an RSA function. A reset is a normal event, and here it undid a lock that should have survived.
Think of a deadbolt where the handle on the inside can also slide the bolt back. The door is "locked" and still opens for anyone who finds the handle.
What an attacker gains
MITRE lists an access control impact with the ability to modify memory, rated high. Registers protected by the lock bit can be modified even when the lock is set. Whatever the lock guarded, such as memory protection configuration, is open again.
How to find it
MITRE describes a manual analysis with high effectiveness:
- Set the lock bit.
- Power cycle the device.
- Attempt to clear the lock bit.
- If the protected information changes, implement a design fix and retest.
MITRE adds that you should also try to clear the lock bit indirectly, or bypass it. Think about resets, other registers that alias the same state, and alternative access paths.
How to fix it
MITRE's mitigation, rated high effectiveness, 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 both pre-silicon and post-silicon testing.
Some practical points follow from the description and the CVE:
- Define explicitly which events can clear the bit, and aim for none short of a full reset to a known secure state.
- Confirm that a reset does not return protected registers to a permissive state before trusted firmware reprograms them.
- Retest after every design change, since a fix to one path can open another.
Quick check
What is the manual test for this weakness?
Set the lock bit, power cycle, attempt to clear it, and see whether the protected information changes. Also try indirect clears and bypasses.
What happened in CVE-2017-6283?
A chip reset cleared critical read and write lock permissions for an RSA function, so a lock that should have held did not.
When should lock behavior be tested?
In both pre-silicon and post-silicon testing, per MITRE's mitigation.
