Weakness · High
CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code
What it is
The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.
- Severity (our rating)
- High
- Likelihood of exploit
- Not rated by MITRE
- Introduced during
- Architecture and Design
- Exploited in the wild
- No CVE in CISA's catalog
In more detail
Adversaries could bypass the secure-boot process and execute their own untrusted, malicious boot code. As a part of a secure-boot process, the read-only-memory (ROM) code for a System-on-Chip (SoC) or other system fetches bootloader code from Non-Volatile Memory (NVM) and stores the code in Volatile Memory (VM), such as dynamic, random-access memory (DRAM) or static, random-access memory (SRAM). The NVM is usually external to the SoC, while the VM is internal to the SoC. As the code is transferred from NVM to VM, it is authenticated by the SoC's ROM code.
What an attacker can do
- Modify Memory (Access Control, Integrity)
- Execute Unauthorized Code or Commands (Access Control, Integrity)
- Gain Privileges or Assume Identity (Access Control, Integrity)
How to prevent it
Architecture and Design
- Ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code.
Testing
- Test the volatile-memory protections to ensure they are safe from modification or untrusted code.
How to find it
- Manual Analysis. Ensure the volatile memory is lockable or has locks. Ensure the volatile memory is locked for writes from untrusted agents or adversaries. Try modifying the volatile memory from an untrusted agent, and ensure these writes are dropped.
- Manual Analysis. Analyze the device using the following steps: Identify all fabric master agents that are active during system Boot Flow when initial code is loaded from Non-volatile storage to volatile memory. Identify the volatile memory regions that are used for storing loaded system executable program. During system boot, test programming the identified memory regions in step 2 from all the masters identified in step 1. Only trusted masters should be allowed to write to the memory regions. For example, pluggable device peripherals should not have write access to program load memory regions.
H2 Security
Found it in your code?
We review where it appears, fix it with your team, and check it was not already used against you.
Talk to our teamT Academy
Stop writing it in the first place
Learn to build software and systems without weaknesses like this one, with practice on real hosts in your browser, every objective checked on the machine.
Start freeSource: MITRE Common Weakness Enumeration, CWE version 4.19.1. CWE is a trademark of The MITRE Corporation.