CWE-1282 covers data that the design treats as immutable, such as a first stage bootloader, device identifiers and write-once configuration settings, but which sits in memory that can be reprogrammed in the field.
How it happens
Security services like secure boot, authentication of code and data, and device attestation depend on assets that are trusted implicitly: the first stage bootloader, public keys, golden hash digests. Storing them in read-only memory (ROM), fuses or one-time programmable (OTP) memory gives strong integrity guarantees and a root of trust for the rest of the system.
When those assets live in memory that can be rewritten, the guarantee disappears. An attacker who can write that memory can replace the trusted key or hash and make their own code pass verification.
What an attacker gains
Integrity loss, varying by context. Since everything else is verified against the root of trust, changing it undermines the whole chain.
How to find it
No detection methods are listed. List every asset the design assumes immutable, then record where each is stored and who can write to it. Any entry that is not ROM, fuse or OTP needs a justification.
How to fix it
- Put the root of trust assets in ROM, fuses or OTP memory.
- Lock any write-once settings so they truly cannot change after provisioning.
- Test by attempting writes to each of these assets from software and from debug interfaces.
Quick check
Which storage types give strong integrity for a root of trust?
Read-only memory, fuses and one-time programmable memory.
