CWE-1261 is the weakness of hardware logic that does not handle single-event upsets (SEUs) well. It matters to anyone designing chips with security-sensitive modules, including safety critical and medical devices.
How it happens
Shrinking CMOS transistors, new materials and SoC designs make systems more sensitive to soft errors. These errors are random, with internal causes such as interconnect coupling or external ones such as cosmic radiation. They are not permanent. They cause temporary bit flips, called single-event upsets, when charged particles ionize the material they pass through and leave electron-hole pairs behind.
If the flip lands in a security-sensitive module, the chip's security guarantees can break. MITRE's own illustration is a bit flip that changes a regular user's privilege to root.
Two examples in the record. In the first, memory parity checks fail after bit flips, causing a restart and a temporary denial of service of two to three minutes. Parity detects errors but cannot correct them. In the second, in 2016 a security researcher who used a pacemaker was on a plane when a bit flip occurred in it, probably because of higher cosmic radiation at that height. The pacemaker was designed for bit flips and went into a default safe mode, which still sent the patient to hospital to reset it. The flip also let the researcher access the crash file, reverse engineer it and find a hard-coded key.
What an attacker gains
The record lists availability (crash, restart, instability) and access control: gaining privileges or assuming identity, and bypassing protection mechanisms. An attacker does not control a random flip, but a defender should not rely on luck, and flips can be provoked by physical means.
How to find it
The record has no detection methods. Review which security-critical state lives in memory and registers, and what protects it against flips. Memory that has only parity checking, or nothing, is the first place to look.
How to fix it
MITRE's mitigations, at design:
- Use triple-modular redundancy around security-sensitive modules.
- SEUs mostly affect SRAMs, so for SRAMs that store security-critical data, implement error-correcting codes and address interleaving.
The first example shows the payoff. Error-correcting codes could have avoided the restart that parity-only detection caused.
Quick check
Why is parity not enough?
Parity detects errors but cannot correct them, so a flip leads to a restart or failure instead of a recovery.
Which memory is most affected by SEUs?
SRAM, according to MITRE, so SRAMs holding security-critical data should use ECC and address interleaving.
