CWE-1317 is about a bridge that skips its checks. The product uses a fabric bridge for transactions between two Intellectual Property (IP) blocks, but the bridge does not properly perform the expected privilege, identity or other access control checks between them.
How it happens
In hardware designs, IP blocks connect through interconnect-bus fabrics such as AHB and OCP. Inside a System on Chip (SoC), subsystems may use different bus protocols. A fabric bridge links them to the central bus and to each other, routing and translating transactions.
For system security, the privileges tied to a transaction must stay consistent and enforced even after routing or translation. MITRE names two ways a bridge fails:
- A bridge connected to a fabric without security features forwards transactions to the slave without checking the master's privilege level.
- A bridge does not check the hardware identity of a transaction received from its slave interface.
Either way, access control that exists on paper does not exist at the bridge.
The record's observed example is CVE-2019-6260. A Baseboard Management Controller (BMC) device implements AHB bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space. MITRE's demonstrative example describes the iLPC2AHB bridge connecting a CPU with multiple privilege levels, such as user, super user and debug, over AHB to an LPC bus with several peripherals. The bridge is expected to check the privilege level of transactions before forwarding them. It does not implement the checks and allows reads and writes from all privilege levels.
What an attacker gains
MITRE rates the likelihood as medium. Consequences: bypass of protection mechanisms, reading and modifying memory, crash or restart, with confidentiality, integrity, access control and availability affected.
How to find it
Two methods are listed, both rated high:
- Simulation or emulation: RTL simulation to ensure bridge access controls are implemented properly.
- Formal verification: formal verification of the bridge RTL to ensure access control cannot be bypassed.
Add negative tests to the simulation. Send transactions from every privilege level through the bridge to every protected peripheral behind it and confirm that only the allowed combinations succeed.
How to fix it
MITRE's guidance has two parts. At design time, include provisions for access control checks in the bridge for both upstream and downstream transactions. At implementation time, build those checks for both directions.
For the BMC-style case, MITRE's example adds that designers should implement hardware-based checks that are hardcoded to block untrusted agents from accessing secure peripherals, or firmware flows that configure the bridge to block untrusted agents.
Quick check
Why check both upstream and downstream?
Transactions cross the bridge in both directions, and either direction can carry an untrusted request to something protected.
What does CVE-2019-6260 show?
AHB bridges that need no authentication for read and write access to the BMC's physical address space.
