CWE-1316
Alerte pour un CWE
Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges
Extended Description
Various ranges can be defined in the system-address map, either in the memory or in Memory-Mapped-IO (MMIO) space. These ranges are usually defined using special range registers that contain information, such as base address and size. Address decoding is the process of determining for which range the incoming transaction is destined. To ensure isolation, ranges containing secret data are access-control protected.
Occasionally, these ranges could overlap. The overlap could either be intentional (e.g. due to a limited number of range registers or limited choice in choosing size of the range) or unintentional (e.g. introduced by errors). Some hardware designs allow dynamic remapping of address ranges assigned to peripheral MMIO ranges. In such designs, intentional address overlaps can be created through misconfiguration by malicious software. When protected and unprotected ranges overlap, an attacker could send a transaction and potentially compromise the protections in place, violating the principle of least privilege.
Informations
Modes Of Introduction
Architecture and DesignImplementation
Applicable Platforms
Language
Class: Not Language-Specific (Undetermined)Operating Systems
Class: Not OS-Specific (Undetermined)Architectures
Class: Not Architecture-Specific (Undetermined)Technologies
Name: Bus/Interface Hardware (Undetermined)Class: Not Technology-Specific (Undetermined)
Common Consequences
| Scope | Impact | Likelihood |
|---|---|---|
| Confidentiality Integrity Access Control Authorization | Bypass Protection Mechanism, Read Memory, Modify Memory | Medium |
Observed Examples
| Reference | Description |
|---|---|
| Attacker can modify MCHBAR register to overlap with an attacker-controlled region, which modification prevents the SENTER instruction from properly applying VT-d protection while a Measured Launch Environment is being launched. |
Potential Mitigations
Phases : Architecture and DesignWhen architecting the address map of the chip, ensure that protected and unprotected ranges are isolated and do not overlap. When designing, ensure that ranges hardcoded in Register-Transfer Level (RTL) do not overlap.
Phases : Implementation
Ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, then ensure that no assets are present in the overlapped portion.
Phases : Testing
Validate mitigation actions with robust testing.
Detection Methods
Automated Dynamic Analysis
Review address map in specification to see if there are any overlapping ranges.Effectiveness : High
Manual Static Analysis
Negative testing of access control on overlapped ranges.Effectiveness : High
Vulnerability Mapping Notes
Rationale : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.Comments : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Related Attack Patterns
| CAPEC-ID | Attack Pattern Name |
|---|---|
| CAPEC-456 | Infected Memory An adversary inserts malicious logic into memory enabling them to achieve a negative impact. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems that are still under development and part of the supply chain. |
| CAPEC-679 | Exploitation of Improperly Configured or Implemented Memory Protections An adversary takes advantage of missing or incorrectly configured access control within memory to read/write data or inject malicious code into said memory. |
Notes
As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.References
REF-1137
BARing the System - New vulnerabilities in Coreboot & UEFI-based SystemsYuriy Bulygin, Oleksandr Bazhaniuk, Andrew Furtak, John Loucaides, Mikhail Gorobets.
https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf
Submission
| Name | Organization | Date | Date Release | Version |
|---|---|---|---|---|
| Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna | Intel Corporation | 4.3 |
Modifications
| Name | Organization | Date | Comment |
|---|---|---|---|
| CWE Content Team | MITRE | updated Maintenance_Notes | |
| CWE Content Team | MITRE | updated Applicable_Platforms, Related_Attack_Patterns | |
| CWE Content Team | MITRE | updated Applicable_Platforms | |
| CWE Content Team | MITRE | updated References | |
| CWE Content Team | MITRE | updated Related_Attack_Patterns | |
| CWE Content Team | MITRE | updated Relationships | |
| CWE Content Team | MITRE | updated Mapping_Notes |
