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.
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.
Potential Impact
Confidentiality, Integrity, Availability, Access Control
Modify Memory, Read Memory, DoS: Resource Consumption (Other), Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Alter Execution Logic, Bypass Protection Mechanism, Quality Degradation
Demonstrative Examples
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 @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;
always @ (posedge clk or negedge rst_n)
if (!rst_n)
begin
q <= 32'h0;
data_out <= 32'h0;
end
else
begin
q <= (addr_auth & write_auth) ? data_in: q;
data_out <= q;
end
end
endmoduleassign addr_auth = (address == 32'hF00) ? 1: 0;assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;Mitigations & Prevention
Protect assets from accesses against all potential interfaces and alternate paths.
Protect assets from accesses against all potential interfaces and alternate paths.
Protect assets from accesses against all potential interfaces and alternate paths.
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2022-38399 | Missing protection mechanism on serial connection allows for arbitrary OS command execution. |
| CVE-2020-9285 | 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 corresponding GPIO resource registers, protection can be bypassed by writing to the |
| CVE-2020-15483 | monitor device allows access to physical UART debug port without authentication |
Related Weaknesses
Frequently Asked Questions
What is CWE-1299?
CWE-1299 (Missing Protection Mechanism for Alternate Hardware Interface) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allo...
How can CWE-1299 be exploited?
Attackers can exploit CWE-1299 (Missing Protection Mechanism for Alternate Hardware Interface) to modify memory, read memory, dos: resource consumption (other), execute unauthorized code or commands, gain privileges or assume identity, alter execution logic, bypass protection mechanism, quality degradation. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-1299?
Key mitigations include: Protect assets from accesses against all potential interfaces and alternate paths.
What is the severity of CWE-1299?
CWE-1299 is classified as a Base-level weakness (Medium abstraction). It has been observed in 5 real-world CVEs.