New to CAPEC? Start Here
Home > CAPEC List > CAPEC-679: Exploitation of Improperly Configured or Implemented Memory Protections (Version 3.9)  

CAPEC-679: Exploitation of Improperly Configured or Implemented Memory Protections

Attack Pattern ID: 679
Abstraction: Detailed
View customized information:
+ Description

An adversary takes advantage of missing or incorrectly configured access control within memory to read/write data or inject malicious code into said memory.

+ Extended Description

Hardware product designs often need to implement memory protection features to prevent users from reading and modifying memory reserved for security operations such as secure booting, authenticating code, device attestation, and more. However, these protection features may be missing if not configured by developers. For example, this can occur if the developers assume these features are configured elsewhere. Additionally, developers often attempt to impose proper protection features, but may incorrectly configure these controls. One such example would be setting controls with insufficient granularity for protected address regions. If an adversary is able to discover improper access controls surrounding memory, it could result in the adversary obtaining sensitive data, executing code, circumventing security mechanisms, escalating privileges, or even denying service to higher privilege software.

+ Likelihood Of Attack

Medium

+ Typical Severity

Very High

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.1Accessing Functionality Not Properly Constrained by ACLs
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.180Exploiting Incorrectly Configured Access Control Security Levels
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Prerequisites
Access to the hardware being leveraged.
+ Skills Required
[Level: Medium]
Ability to craft malicious code to inject into the memory region.
[Level: High]
Intricate knowledge of memory structures.
+ Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity
Modify Data
Confidentiality
Read Data
Confidentiality
Integrity
Availability
Execute Unauthorized Commands
Confidentiality
Access Control
Authorization
Gain Privileges
+ Mitigations
Ensure that protected and unprotected memory ranges are isolated and do not overlap.
If memory regions must overlap, leverage memory priority schemes if memory regions can overlap.
Ensure that original and mirrored memory regions apply the same protections.
Ensure immutable code or data is programmed into ROM or write-once memory.
+ Example Instances

A hardware product contains non-volatile memory, which itself contains boot code that is insufficiently protected. An adversary then modifies this memory to either bypass the secure boot process or to execute their own code.

A hardware product leverages a CPU that does not possess a memory-protection unit (MPU) and a memory-management unit (MMU) nor a special bit to support write exclusivity, resulting in no write exclusivity. Because of this, an adversary is able to inject malicious code into the memory and later execute it to achieve the desired outcome.

+ Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see parents CAPEC-1, CAPEC-180 )
+ References
[REF-687] "Cortex-R4 Manual". ARM. <https://developer.arm.com/ip-products/processors/cortex-m/cortex-m4>. URL validated: 2021-10-21.
[REF-689] "Memory Protection Unit (MPU)". ARM. <https://static.docs.arm.com/100699/0100/armv8m_architecture_memory_protection_unit_100699_0100_00_en.pdf>. URL validated: 2021-10-21.
[REF-690] Christopher Domas. "The Memory Sinkhole". 2015-07-20. <https://github.com/xoreaxeaxeax/sinkhole/blob/master/us-15-Domas-TheMemorySinkhole-wp.pdf>. URL validated: 2021-10-21.
[REF-691] "Address Range Memory Mirroring". Taku Izumi, Fujitsu Limited. 2016-07-13. <https://www.fujitsu.com/jp/documents/products/software/os/linux/catalog/LinuxConJapan2016-Izumi.pdf>. URL validated: 2021-10-21.
[REF-692] Yuriy Bulygin, Oleksandr Bazhaniuk, Andrew Furtak, John Loucaides and Mikhail Gorobets. "BARing the System – New vulnerabilities in Coreboot & UEFI-based Systems". 2017. <https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf>. URL validated: 2021-10-21.
+ Content History
Submissions
Submission DateSubmitterOrganization
2021-10-21
(Version 3.6)
CAPEC Content TeamThe MITRE Corporation
More information is available — Please select a different filter.
Page Last Updated or Reviewed: October 21, 2021