CWE-1260 Base Estable

Improper Handling of Overlap Between Protected Memory Ranges

This vulnerability occurs when a system incorrectly allows different memory protection ranges to overlap. This flaw can let attackers bypass security controls and access restricted memory areas.

Definición

What is CWE-1260?

This vulnerability occurs when a system incorrectly allows different memory protection ranges to overlap. This flaw can let attackers bypass security controls and access restricted memory areas.
Modern hardware uses isolated memory regions with specific read/write permissions to protect sensitive software, like an operating system kernel. Lower-privilege software, such as an application, is sometimes allowed to reconfigure these memory maps. If that software can program an overlapping region that intrudes into a higher-privilege area, it creates a critical security gap. The Memory Protection Unit (MPU) may fail to properly resolve this overlap, allowing the lower-privilege software to read or write into protected memory. This typically leads to privilege escalation, giving an attacker unauthorized control. Alternatively, an attacker could use this overlap to corrupt critical memory, causing a denial-of-service crash in the more privileged software.
Impacto en el mundo real

Real-world CVEs caused by CWE-1260

  • virtualization product allows compromise of hardware product by accessing certain remapping registers.

  • 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]

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

  1. 1

    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.write_np: if set to one, allows writes from Non_privileged_SW - Access_policy.execute_np: if set to one, allows code execution by Non_privileged_SW - Access_policy.read_p: if set to one, allows reads from Privileged_SW - Access_policy.write_p: if set to one, allows writes from Privileged_SW - Access_policy.execute_p: if set to one, allows code execution by Privileged_SW For any requests from software, an address-protection filter checks the address range and access policies for each of the three regions, and only allows software access if all three filters allow access. Consider the following goals for access control as intended by the designer: - Region_0 & Region_1: registers are programmable by Privileged_SW - Region_2: registers are programmable by Non_privileged_SW The intention is that Non_privileged_SW cannot modify memory region and policies defined by Privileged_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privileged_SW is using.

  2. 2

    This design could be improved in several ways.

  3. 3

    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).

  4. 4

    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.

  5. 5

    The vulnerable code allows the overlap between the protected MMIO region of the AES peripheral and the unprotected UART MMIO region. As a result, unprivileged users can access the protected region of the AES IP. In the given vulnerable example UART MMIO region starts at address 64'h1000_0000 and ends at address 64'h1011_1000 (UARTBase is 64'h1000_0000, and the size of the region is provided by the UARTLength of 64'h0011_1000).

Ejemplo de código vulnerable

Vulnerable code

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.write_np: if set to one, allows writes from Non_privileged_SW - Access_policy.execute_np: if set to one, allows code execution by Non_privileged_SW - Access_policy.read_p: if set to one, allows reads from Privileged_SW - Access_policy.write_p: if set to one, allows writes from Privileged_SW - Access_policy.execute_p: if set to one, allows code execution by Privileged_SW For any requests from software, an address-protection filter checks the address range and access policies for each of the three regions, and only allows software access if all three filters allow access. Consider the following goals for access control as intended by the designer: - Region_0 & Region_1: registers are programmable by Privileged_SW - Region_2: registers are programmable by Non_privileged_SW The intention is that Non_privileged_SW cannot modify memory region and policies defined by Privileged_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privileged_SW is using.

Vulnerable
Non_privileged_SW can program the Address_range register for Region_2 so that its address overlaps with the ranges defined by Region_0 or Region_1. Using this capability, it is possible for Non_privileged_SW to block any memory region from being accessed by Privileged_SW, i.e., Region_0 and Region_1.
Ejemplo de código seguro

Secure code

This design could be improved in several ways.

Seguro
Ensure that software accesses to memory regions are only permitted if all three filters permit access. Additionally, the scheme could define a memory region priority to ensure that Region_2 (the memory region defined by Non_privileged_SW) cannot overlap Region_0 or Region_1 (which are used by Privileged_SW).
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Lista de prevención

How to prevent CWE-1260

  • 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 address is within multiple regions, then the region with the lowest ID takes priority and the access-control policy of that region will be applied. In some MPU designs, the priority scheme can also be programmed by trusted software. Hardware logic or trusted firmware can also check for region definitions and block programming of memory regions with overlapping addresses. The memory-access-control-check filter can also be designed to apply a policy filter to all of the overlapping ranges, i.e., if an address is within Region_0 and Region_1, then access to this address is only granted if both Region_0 and Region_1 policies allow the access.
Señales de detección

How to detect CWE-1260

Manual Analysis High

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 hardware. Repeat the test.

Auto-corrección de Plexicus

Plexicus detecta automáticamente CWE-1260 y abre un PR de corrección en menos de 60 segundos.

Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.

Preguntas frecuentes

Frequently asked questions

¿Qué es CWE-1260?

This vulnerability occurs when a system incorrectly allows different memory protection ranges to overlap. This flaw can let attackers bypass security controls and access restricted memory areas.

¿Qué gravedad tiene CWE-1260?

MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.

¿Qué lenguajes o plataformas se ven afectados por CWE-1260?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Memory Hardware, Processor Hardware.

¿Cómo puedo prevenir CWE-1260?

Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software. 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 address is within multiple regions, then the region with the…

¿Cómo detecta y corrige Plexicus CWE-1260?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-1260 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.

¿Dónde puedo aprender más sobre CWE-1260?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/1260.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Debilidades relacionadas

Weaknesses related to CWE-1260

CWE-284 Padre

Improper Access Control

The software fails to properly limit who can access a resource, allowing unauthorized users or systems to interact with it.

CWE-1191 Hermano

On-Chip Debug and Test Interface With Improper Access Control

This vulnerability occurs when a hardware chip's debug or test interface (like JTAG) lacks proper access controls. Without correct…

CWE-1220 Hermano

Insufficient Granularity of Access Control

This vulnerability occurs when a system's access controls are too broad, allowing unauthorized users or processes to read or modify…

CWE-1224 Hermano

Improper Restriction of Write-Once Bit Fields

This vulnerability occurs when hardware write-once protection mechanisms, often called 'sticky bits,' are incorrectly implemented,…

CWE-1231 Hermano

Improper Prevention of Lock Bit Modification

This vulnerability occurs when hardware or firmware uses a lock bit to protect critical system registers or memory regions, but fails to…

CWE-1233 Hermano

Security-Sensitive Hardware Controls with Missing Lock Bit Protection

This vulnerability occurs when a hardware device uses a lock bit to protect critical configuration registers, but the lock fails to…

CWE-1252 Hermano

CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

This vulnerability occurs when a CPU's hardware is not set up to enforce a strict separation between writing data to memory and executing…

CWE-1257 Hermano

Improper Access Control Applied to Mirrored or Aliased Memory Regions

This vulnerability occurs when a hardware design maps the same physical memory to multiple addresses (aliasing or mirroring) but fails to…

CWE-1259 Hermano

Improper Restriction of Security Token Assignment

This vulnerability occurs when a System-on-a-Chip (SoC) fails to properly secure its Security Token mechanism. These tokens control which…

Listo cuando tú lo estés

Deja de pagar por desarrollador.
Empieza a cerrar el bucle.

Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.