CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges

Description:
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.

Extended Description:
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, privilege escalation may be available to attackers. 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. An address overlap weakness can also be used to launch a denial of service attack on the higher-privilege software memory regions.

Affected languages: Not Language-Specific
Affected technologies: Memory Hardware, Processor Hardware
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: Modify Memory

Detection methods:
  - Manual Analysis: Create a high privilege memory block of any arbitrary size. Attempt to create a lower privilege memory block with an overlap of the high privilege memory block. If the creation attempt works, fix the 

Mitigations:
  - [Architecture and Design] Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software.
  - [Implementation] For all of the programmable memory protection regions, the memory protection unit (MPU) design can define a priority scheme. 
                  For example: if three memory regions can be programmed (Region_0, Region_1, and Region_2), the design can enforce a priority scheme, such that, if a system 

Demonstrative examples:
For example, consider a design with a 16-bit address that has two software privilege levels: Privileged_SW and Non_privileged_SW. To isolate the system memory regions accessible by these two privilege levels, the design supports three memory regions: Region_0, Region_1, and Region_2. 
		 Each region is defined by two 32 bit registers: its range and its 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[31:0]: specifies what types of software can access a region and which actions are allowed 
		 
		 Certain bits of the access policy are defined symbolically as follows: 
		 
		   Access_policy.read_np: if set to one, allows reads from Non_privileged_SW 
		   Access_policy.writ

The example code below is taken from the IOMMU controller module of the HACK@DAC'19 buggy CVA6 SoC [REF-1338]. The static memory map is composed of a set of Memory-Mapped Input/Output (MMIO) regions covering different IP agents within the SoC. Each region is defined by two 64-bit variables representing the base address and size of the memory region (XXXBase and XXXLength).
In this example, we have 12 IP agents, and only 4 of them are called out for illustration purposes in the code snippets. Access to the AES IP MMIO region is considered privileged as it provides access to AES secret key, internal states, or decrypted data.
...
						 
							localparam logic[63:0] PLICLength = 64'h03FF_FFFF; 
							 localparam logic[63:0] UARTLength = 64'h0011_1000; 
							 localparam logic[63:0] AESLen

Real-world examples:
  - CVE-2008-7096: virtualization product allows compromise of hardware product by accessing certain remapping registers.
  - [REF-1100]: processor design flaw allows ring 0 code to access more privileged rings by causing a register window to overlap a range of protected system RAM [REF-1100]