CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
Isolated memory regions and access control (read/write) policies are used by hardware to protect privileged software. Software components are often allowed to change or remap memory region definitions in order to enable flexible and dynamically changeable memory management by system software.
If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege software a weakness is available for abuse. The memory protection unit (MPU) logic can incorrectly handle such an address overlap and allow the lower privilege software to read or write into the protected memory region resulting in privilege escalation attack. Address overlap weakness can also be used to launch a denial of service attack on the higher privilege software memory regions.
The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Class: Language-Independent (Undetermined Prevalence)
Class: OS-Independent (Undetermined Prevalence)
Class: Architecture-Independent (Undetermined Prevalence)
Memory IP (Undetermined Prevalence)
Processor IP (Undetermined Prevalence)
The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. 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 weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
For example, consider an example design with 16-bit address that has two software privilege levels: Privilege_SW and Non_privilege_SW.
To isolate the system memory regions accessible by these two privilege levels, the design
supports three memory regions: Region_0, Region_1, Region_2.
- Region_0 & Region_1: registers are programmable by Privilege_SW
- Region_2: registers are programmable by Non_privilege_SW
Each region range is defined by two 32 bit registers Address_range and Access_policy:
- Address_range[15:0]: specifies the Base address of the region
- Address_range[31:16]: specifies the size of the region
- Access_policy: if set to one, allows reads from Non_privilege_SW
- Access_policy: if set to one, allows writes from Non_privilege_SW
- Access_policy: if set to one, allows reads from Privilege_SW
- Access_policy: if set to one, allows writes from Privilege_SW
The address-protection filter checks the address range and access policies of all three regions and only allows software access if all three filters allow access.
In this design example, Non_privilege_SW cannot modify memory region and policies defined by Privilege_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privilege_SW is using.
However, Non_privilege_SW can program Region_2 registers to overlap with Region_0 or Region_1, and it can also define the access policy of Region_2. Using this capability, it is possible for Non_privilege_SW to block any memory region from being accessed by Privilege_SW, including the memory regions protected by Region_0 and Region_1.
In such a design, a memory region priority should be defined to ensure that the memory region defined by Non_privilege_SW in Region_2 cannot change the access policy defined in Region_0 or Region_1.
More information is available — Please select a different filter.