CWE-1299 is the hardware version of locking the front door and leaving the side door open. Protections are applied to the primary path to an asset, but alternate paths, such as unprotected shadow registers and other external-facing interfaces, are left unguarded. An attacker simply uses the path nobody protected.
The same shape appears in web applications as an admin API with authentication on one route but not on its twin. Here it lives inside chips, microcontrollers and processors.
How it happens
An asset inside a chip can have access control on one interface. If every path to the asset is not protected, an attacker can reach it another way. MITRE names two kinds of alternate path.
- Other interfaces. Consider an SoC with UART, SMBUS, PCIe and USB. If access control for internal registers is implemented only for the PCIe interface, an attacker can still modify those registers by coming in through UART, SMBUS or USB.
- Shadow or mirror registers. These are registers reachable from more than one address, where reading or writing the aliased address has the same effect as using the main register. They are typically used inside an IP core or SoC to hold data temporarily before it is moved to the main register, and both are kept in sync. If the shadow register is not access-protected, an attacker can transact with it and compromise the system.
MITRE's demonstrative example is in Verilog and applies to VHDL too. A register called SECURE_ME sits at address 0xF00. A mirror, COPY_OF_SECURE_ME, sits at 0x800F00. The main register is protected from malicious agents and allows access only to select initiators, using an allowlist. The mirror is not protected. The address check is the bug:
// BAD: only the primary address is checked
assign addr_auth = (address == 32'hF00) ? 1 : 0;
Writing to the mirror modifies SECURE_ME. The fix is to include the mirror's address in the check:
// GOOD: both addresses go through the same authorization
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1 : 0;
What an attacker gains
MITRE rates the likelihood of exploit as high. Consequences listed: reading and modifying memory, executing unauthorized code or commands, gaining privileges or assuming identity, altering execution logic, bypassing protection mechanisms, resource-consumption denial of service and quality degradation.
The observed examples show how varied the alternate paths are:
- CVE-2022-38399: a missing protection mechanism on a serial connection allows arbitrary OS command execution.
- CVE-2020-9285: a Mini-PCI Express slot does not restrict direct memory access.
- CVE-2020-8004: when the internal flash is protected by blocking access on the Data Bus (DBUS), it can still be indirectly accessed through the Instruction Bus (IBUS).
- CVE-2017-18293: when GPIO is protected by blocking access to the corresponding GPIO resource registers, the protection can be bypassed by writing to the corresponding banked GPIO registers instead.
Three of the four are the same story. Something was blocked on one route and still reachable through a sibling.
How to find it
The record lists no detection methods. Build the inventory first, then test it.
- List every asset that has access control: keys, configuration registers, flash, GPIO, debug state.
- For each, list every path that can reach it. Include every external interface, every internal bus, and every mirror, shadow or banked copy of the register.
- Confirm that each path goes through the same authorization logic, or has an equivalent one.
- Test from each interface as an untrusted agent. Attempt the same read or write through every route and confirm all are denied.
Whenever the address map or the interface list changes, repeat the inventory. New interfaces and new aliases are how this weakness returns after a clean review.
How to fix it
MITRE's single mitigation appears for requirements, architecture and design, and implementation, labelled as defense in depth: protect assets from accesses against all potential interfaces and alternate paths.
To make it work:
- Put access checks at the asset, or at a point every path must cross, instead of per interface.
- Derive the list of protected addresses from one source so mirrors and banked copies cannot be forgotten, as in the Verilog fix above.
- Treat any new interface as untrusted until it has been run through the same checks.
- Keep the path inventory in the design documents and update it with each change.
If you are a consumer of devices rather than a designer, the same lens applies to products you integrate. Ask which serial, debug and expansion interfaces are exposed, and whether each one is protected equally.
Quick check
What is a shadow register?
A register reachable from more than one address, where using the alias has the same effect as using the main register.
Why is it risky to protect only the PCIe path?
Other interfaces such as UART, SMBUS or USB may reach the same internal registers without the check.
What is the fix in MITRE's Verilog example?
Add the mirror address to the authorization check so both addresses are treated the same.
