|
|
|
|
CAPEC-679: Exploitation of Improperly Configured or Implemented Memory Protections |
 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 Typical Severity 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  This 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.| Scope | Impact | Likelihood |
|---|
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 CAPEC 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. References  Content History | Submissions |
|---|
| Submission Date | Submitter | Organization |
|---|
| 2021-10-21 (Version 3.6) | CAPEC Content Team | The MITRE Corporation | |
More information is available — Please select a different filter.
|
