CWE-1319: Improper Protection against Electromagnetic… | Glexia
CWE-1319 (Improper Protection against Electromagnetic Fault Injection (EM-FI)) weakness overview with consequences, detection methods, mitigations, related CVEs…
Glexia's Take · Automated analysis
CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI)
Improper Protection against Electromagnetic Fault Injection (EM-FI) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Confidentiality Integrity Access Control Availability: Modify Memory Read Memory Gain Privileges or Assume Identity Bypass Protection Mechanism Execute Unauthorized Code or Commands
Developer Pattern
CWE-1319 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-1319, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI)
The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.
Electromagnetic fault injection may allow an attacker to locally and dynamically modify the signals (both internal and external) of an integrated circuit. EM-FI attacks consist of producing a local, transient magnetic field near the device, inducing current in the device wires. A typical EMFI setup is made up of a pulse injection circuit that generates a high current transient in an EMI coil, producing an abrupt magnetic pulse which couples to the target producing faults in the device, which can lead to: Bypassing security mechanisms such as secure JTAG or Secure Boot Leaking device information Modifying program flow Perturbing secure hardware modules (e.g. random number generators)
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- In many devices, security related information is stored in fuses. These fuses are loaded into shadow registers at boot time. Disturbing this transfer phase with EM-FI can lead to the shadow registers storing erroneous values potentially resulting in reduced security. Colin O'Flynn has demonstrated an attack scenario [REF-1144] that uses electro-magnetic glitching during booting to bypass security and gain read access to flash, read and erase access to shadow memory area (where the private password is stored). Most devices in the MPC55xx and MPC56xx series that include the Boot Assist Module (BAM) (a serial or CAN bootloader mode) are susceptible to this attack. In this paper, a GM ECU was used as a real life target. While the success rate appears low (less than 2 percent), in practice a success can be found within 1-5 minutes once the EMFI tool is setup. In a practical scenario, the author showed that success can be achieved within 30-60 minutes from a cold start.
Remediation
- Architecture and Design Implementation: 1. Redundancy - By replicating critical operations and comparing the two outputs can help indicate whether a fault has been injected. 2. Error detection and correction codes - Gay, Mael, et al. proposed a new scheme that not only detects faults injected by a malicious adversary but also automatically corrects single nibble/byte errors introduced by low-multiplicity faults. 3. Fail by default coding - When checking conditions (switch or if) check all possible cases and fail by default because the default case in a switch (or the else part of a cascaded if-else-if construct) is used for dealing with the last possible (and valid) value without checking. This is prone to fault injection because this alternative is easily selected as a result of potential data manipulation [REF-1141]. 4. Random Behavior - adding random delays before critical operations, so that timing is not predictable. 5. Program Flow Integrity Protection - The program flow can be secured by integrating run-time checking aiming at detecting control flow inconsistencies. One such example is tagging the source code to indicate the points not to be bypassed [REF-1147]. 6. Sensors - Usage of sensors can detect variations in voltage and current. 7. Shields - physical barriers to protect the chips from malicious manipulation.
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.