Missing Protection Mechanism for Alternate Hardware Interface
This vulnerability occurs when a hardware component's security controls only protect the primary access path, leaving alternate interfaces unprotected. Attackers can bypass intended restrictions by accessing sensitive assets through these unguarded backdoors, such as shadow registers or other external-facing ports.
Modern chips and Systems-on-Chip (SoCs) often contain multiple access paths to critical internal registers—through interfaces like PCIe, USB, UART, or SMBus. If access controls are only enforced on one primary interface (e.g., PCIe), an attacker can simply route malicious transactions through an alternate, unprotected interface (like UART or USB) to modify or read protected registers, completely bypassing the intended security layer. Another common bypass involves shadow or mirror registers, which are duplicate registers that temporarily hold data before syncing with a main register. These are often implemented for performance or debugging purposes. If these shadow registers lack the same access protections as their primary counterparts, attackers can directly target them to alter system state, compromise security configurations, or leak sensitive information, effectively undermining the chip's entire protection scheme.
Impact: Modify MemoryRead MemoryDoS: Resource Consumption (Other)Execute Unauthorized Code or CommandsGain Privileges or Assume IdentityAlter Execution LogicBypass Protection MechanismQuality Degradation
Effectiveness: Defense in Depth
Effectiveness: Defense in Depth
Effectiveness: Defense in Depth
ID : DX-176
Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not. Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset). Though this example is shown in Verilog, it will apply to VHDL as well.Code Example:
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n); output [31:0] data_out; input [31:0] data_in, incoming_id, address; input clk, rst_n; wire write_auth, addr_auth; reg [31:0] data_out, acl_oh_allowlist, q; assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0; always @*
verilogCode Example:
assign addr_auth = (address == 32'hF00) ? 1: 0;
Code Example:
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;