CWE-1317: Improper Access Control in Fabric Bridge
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 those IP blocks.
How it's found
Improper Access Control in Fabric Bridge is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.
In hardware designs, different IP blocks are connected through interconnect-bus fabrics (e.g. AHB and OCP). Within a System on Chip (SoC), the IP block subsystems could be using different bus protocols. In such a case, the IP blocks are then linked to the central bus (and to other IP blocks) through a fabric bridge. Bridges are used as bus-interconnect-routing modules that link different protocols or separate, different segments of the overall SoC interconnect. For overall system security, it is important that the access-control privileges associated with any fabric transaction are consistently maintained and applied, even when they are routed or translated by a fabric bridge. A bridge that is connected to a fabric without security features forwards transactions to the slave without checking the privilege level of the master and results in a weakness in SoC access-control security. The same weakness occurs if a bridge does not check the hardware identity of the transaction received from the slave interface of the bridge.
Vulnerable vs. safe
input logic acct_ctrl_i;
.en_o ( en_acct ),
axi_lite_interface #(...) axi_lite_interface_i (...
assign en = en_acct && acct_ctrl_i;
.en_o ( en ),
axi_lite_interface #(...) axi_lite_interface_i (......module aes0_wrapper #(...)(...);...........);...endmodule...module clint #(...)(...);......);...endmoduleinput logic acct_ctrl_i,
, en_acct
logic en;
axi_lite_interface #(...) axi_lite_interface_i (
en_acct
.en_o (),
assign en = en_acct && acct_ctrl_i;);module clint #(...) (......);............endmoduleConsequences
- DoS: Crash, Exit, or Restart, Bypass Protection Mechanism, Read Memory, Modify Memory
Mitigations
- Architecture and Design: Ensure that the design includes provisions for access-control checks in the bridge for both upstream and downstream transactions.
- Implementation: Implement access-control checks in the bridge for both upstream and downstream transactions.
Where this fits in a TurboPentest engagement
TurboPentest's agentic pentest is powerful and covers a broad range of issues automatically. This particular class is best confirmed in a manual IntegSec engagement, where human pentesters apply deeper methodology and a larger context window than any automated pass.
Frequently asked questions
What is CWE-1317?
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 those IP blocks.
How do you find Improper Access Control in Fabric Bridge?
Improper Access Control in Fabric Bridge is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.
What is the impact of CWE-1317?
DoS: Crash, Exit, or Restart, Bypass Protection Mechanism, Read Memory, Modify Memory
Does TurboPentest test for Improper Access Control in Fabric Bridge?
TurboPentest's agentic pentest is powerful and covers a broad range of issues automatically. This particular class is best confirmed in a manual IntegSec engagement, where human pentesters apply deeper methodology and a larger context window than any automated pass.
Related CWEs
Find these issues before an attacker does
TurboPentest runs an agentic AI pentest against your target and reports findings with proof, from $99 per target.
Start a $99 pentest