CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface
Description
The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.
Submission Date :
Oct. 2, 2019, midnight
Modification Date :
2023-10-26 00:00:00+00:00
Organization :
Intel Corporation
Extended Description
An asset inside a chip might have access-control protections through one interface. However, if all paths to the asset are not protected, an attacker might compromise the asset through alternate paths. These alternate paths could be through shadow or mirror registers inside the IP core, or could be paths from other external-facing interfaces to the IP core or SoC.
Consider an SoC with various interfaces such as UART, SMBUS, PCIe, USB, etc. If access control is implemented for SoC internal registers only over the PCIe interface, then an attacker could still modify the SoC internal registers through alternate paths by coming through interfaces such as UART, SMBUS, USB, etc.
Alternatively, attackers might be able to bypass existing protections by exploiting unprotected, shadow registers. Shadow registers and mirror registers typically refer to registers that can be accessed from multiple addresses. Writing to or reading from the aliased/mirrored address has the same effect as writing to the address of the main register. They are typically implemented within an IP core or SoC to temporarily hold certain data. These data will later be updated to the main register, and both registers will be in synch. If the shadow registers are not access-protected, attackers could simply initiate transactions to the shadow registers and compromise system security.
Example - 1
The bugged line of code is repeated in the Badexample above. Weakness arises from the fact that theSECURE_ME register can be modified by writing to theshadow register COPY_OF_SECURE_ME, the address ofCOPY_OF_SECURE_ME should also be included in the check.That buggy line of code should instead be replaced asshown in the Good Code Snippet below.
acl_oh_allowlist <= 32'h8312;
q <= 32'h0;data_out <= 32'h0;
beginend
q <= (addr_auth & write_auth) ? data_in: q;data_out <= q;
beginend
if (!rst_n)elseend
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 @*assign addr_auth = (address == 32'hF00) ? 1: 0;always @ (posedge clk or negedge rst_n)endmodule
assign addr_auth = (address == 32'hF00) ? 1: 0;
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;
Related Weaknesses
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined to give an overview of the different insight to similar items that may exist at higher and lower levels of abstraction.
Visit http://cwe.mitre.org/ for more details.