CWE-1326 describes hardware where the root of trust is not immutable. The result is the ability to bypass secure boot or run untrusted boot code. It concerns SoC designers and anyone who depends on secure boot for device integrity.
How it happens
A system-on-chip implements secure boot by verifying signed boot code. Before running it, the SoC checks that the code, or the public key that signed it, has not been tampered with. Settings stored in fuses, such as whether secure boot is enabled, are part of this foundation too.
One way to build a root of trust is to store the code and data in memory or fuses. That memory should be locked after provisioning so it cannot be programmed again. If the contents are mutable, an adversary can modify the root of trust and run code of their choice, which compromises secure boot.
MITRE adds a note: for components like ROM, secure patching and update features should still exist, as long as updates are authenticated and authorized.
What an attacker gains
Consequences in the record are authentication and authorization failures: gain privileges or assume identity, execute unauthorized code or commands, and modify memory.
How to find it
MITRE lists two methods, both rated high effectiveness. Automated dynamic analysis can verify that root of trust components are immutable. Architecture or design review should cover root of trust elements and their memory.
How to fix it
- At design time, designate the root of trust for storage in memory that does not allow further programming or writes.
- During implementation and test, demonstrate that the root of trust memory location rejects further programming or writes.
Quick check
Does immutable mean never patchable?
No. MITRE notes that secure patching and update features should be supported for components like ROM, provided updates are authenticated and authorized.
