CWE-1274: Improper Access Control for Volatile Memory… | Glexia
CWE-1274 (Improper Access Control for Volatile Memory Containing Boot Code) weakness overview with consequences, detection methods, mitigations, related CVEs and…
Glexia's Take · Automated analysis
CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code
Improper Access Control for Volatile Memory Containing Boot Code represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Access Control,Integrity: Modify Memory,Execute Unauthorized Code or Commands,Gain Privileges or Assume Identity: If the volatile-memory-region protections or access controls are insufficient to prevent modifications from an adversary or untrusted agent, the secure boot may be bypassed or replaced with the execution of an adversary's code.
Developer Pattern
CWE-1274 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-1274, 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-1274: Improper Access Control for Volatile Memory Containing Boot Code
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.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- A typical SoC secure boot's flow includes fetching the next piece of code (i.e., the boot loader) from NVM (e.g., serial, peripheral interface (SPI) flash), and transferring it to DRAM/SRAM volatile, internal memory, which is more efficient. The memory from where the boot loader executes can be modified by an adversary.
Remediation
- 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.
Detection
- 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:
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.