CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities
New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE-1317: Improper Access Control in Fabric Bridge (4.16)  
ID

CWE-1317: Improper Access Control in Fabric Bridge

Weakness ID: 1317
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
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.
+ Extended Description

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.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Access Control
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Bypass Protection Mechanism; Read Memory; Modify Memory

Medium
+ Potential Mitigations

Phase: Architecture and Design

Ensure that the design includes provisions for access-control checks in the bridge for both upstream and downstream transactions.

Phase: Implementation

Implement access-control checks in the bridge for both upstream and downstream transactions.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1203 Peripherals, On-chip Fabric, and Interface/IO Problems
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Processor Hardware (Undetermined Prevalence)

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

This example is from CVE-2019-6260 [REF-1138]. The iLPC2AHB bridge connects a CPU (with multiple, privilege levels, such as user, super user, debug, etc.) over AHB interface to an LPC bus. Several peripherals are connected to the LPC bus. The bridge is expected to check the privilege level of the transactions initiated in the core before forwarding them to the peripherals on the LPC bus.

The bridge does not implement the checks and allows reads and writes from all privilege levels.

To address this, designers should implement hardware-based checks that are either hardcoded to block untrusted agents from accessing secure peripherals or implement firmware flows that configure the bridge to block untrusted agents from making arbitrary reads or writes.


Example 2

The example code below is taken from the AES and core local interrupt (CLINT) peripherals of the HACK@DAC'21 buggy OpenPiton SoC. The access to all the peripherals for a given privilege level of the processor is controlled by an access control module in the SoC. This ensures that malicious users with insufficient privileges do not get access to sensitive data, such as the AES keys used by the operating system to encrypt and decrypt information. The security of the entire system will be compromised if the access controls are incorrectly enforced. The access controls are enforced through the interconnect-bus fabrics, where access requests with insufficient access control permissions will be rejected.

(bad code)
Example Language: Verilog 
...
module aes0_wrapper #(...)(...);
...
input logic acct_ctrl_i;
...
axi_lite_interface #(...
) axi_lite_interface_i (
...
.en_o ( en_acct ),
...
..);
assign en = en_acct && acct_ctrl_i;
...
endmodule
...
module clint #(...)(...);
...
axi_lite_interface #(...
) axi_lite_interface_i (
...
.en_o ( en ),
...
);
...
endmodule

The previous code snippet [REF-1382] illustrates an instance of a vulnerable implementation of access control for the CLINT peripheral (see module clint). It also shows a correct implementation of access control for the AES peripheral (see module aes0_wrapper) [REF-1381]. An enable signal (en_o) from the fabric's AXI interface (present in both modules) is used to determine if an access request is made to the peripheral. In the case of the AES peripheral, this en_o signal is first received in a temporary signal en_acct. Then, the access request is enabled (by asserting the en signal) only if the request has sufficient access permissions (i.e., acct_ctrl_i signal should be enabled). However, in the case of the CLINT peripheral, the enable signal, en_o, from the AXI interface, is directly used to enable accesses. As a result, users with insufficient access permissions also get full access to the CLINT peripheral.

To fix this, enable access requests to CLINT [REF-1383] only if the user has sufficient access as indicated by the acct_ctrl_i signal in the boolean && with en_acct.

(good code)
Example Language: Verilog 
module clint #(...
) (
...
input logic acct_ctrl_i,
...
);
logic en, en_acct;
...
axi_lite_interface #(...
) axi_lite_interface_i (
...
.en_o ( en_acct ),
...
);
assign en = en_acct && acct_ctrl_i;
...
endmodule

+ Observed Examples
Reference Description
Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].
+ Detection Methods

Simulation / Emulation

RTL simulation to ensure that bridge-access controls are implemented properly.

Effectiveness: High

Formal Verification

Formal verification of bridge RTL to ensure that access control cannot be bypassed.

Effectiveness: High
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-05-19
(CWE 4.3, 2020-12-10) 		Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna Intel Corporation
+ Contributions
Contribution Date Contributor Organization
2023-06-21 Chen Chen, Rahul Kande, Jeyavijayan Rajendran Texas A&M University
suggested demonstrative example
2023-06-21 Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi Technical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification Date Modifier Organization
2021-10-28 CWE Content Team MITRE
updated Observed_Examples
2022-04-28 CWE Content Team MITRE
updated Applicable_Platforms
2022-06-28 CWE Content Team MITRE
updated Applicable_Platforms
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Detection_Factors, Name, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29) 		CWE Content Team MITRE
updated Demonstrative_Examples, References
+ Previous Entry Names
Change Date Previous Entry Name
2022-10-13 Missing Security Checks in Fabric Bridge
Page Last Updated: November 19, 2024
 

Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2024, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.