CWE-1220: Insufficient Granularity of Access Control

Description

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.

Integrated circuits and hardware engines can expose accesses to assets (device configuration, keys, etc.) to trusted firmware or a software module (commonly set by BIOS/bootloader). This access is typically access-controlled. Upon a power reset, the hardware or system usually starts with default values in registers, and the trusted firmware (Boot firmware) configures the necessary access-control protection. A common weakness that can exist in such protection schemes is that access controls or policies are not granular enough. This condition allows agents beyond trusted agents to access assets and could lead to a loss of functionality or the ability to set up the device securely. This further results in security risks from leaked, sensitive, key material to modification of device configuration.

Potential Impact

Confidentiality, Integrity, Availability, Access Control

Modify Memory, Read Memory, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Other

Demonstrative Examples

Consider a system with a register for storing AES key for encryption or decryption. The key is 128 bits, implemented as a set of four 32-bit registers. The key registers are assets and registers, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary access controls. 
                         The read-policy register defines which agents can read the AES-key registers, and write-policy register defines which agents can program or write to those registers. Each register is a 32-bit register, and it can support access control for a maximum of 32 agents. The number of the bit when set (i.e., "1") allows respective action from an agent whose identity matches the number of the bit and, if "0" (i.e., Clear), disallows the respective action to that corresponding agent.

Bad

Register
                                Field description
                            
                            
                                AES_ENC_DEC_KEY_0
                                AES key [0:31] for encryption or decryptionDefault 0x00000000
                            
                            
                                AES_ENC_DEC_KEY_1
                                AES key [32:63] for encryption or decryptionDefault 0x00000000
                            
                            
                                AES_ENC_DEC_KEY_2
                                AES key [64:95] for encryption or decryptionDefault 0x00000000
                            
                            
                                AES_ENC_DEC_KEY_4
                                AES key [96:127] for encryption or decryptionDefault 0x00000000
                            
                            
                                AES_KEY_READ_WRITE_POLICY
                                [31:0] Default 0x00000006 - meaning agent with identities "1" and "2" can both read from and write to key registers

In the above example, there is only one policy register that controls access to both read and write accesses to the AES-key registers, and thus the design is not granular enough to separate read and writes access for different agents. Here, agent with identities "1" and "2" can both read and write.

A good design should be granular enough to provide separate access controls to separate actions. Access control for reads should be separate from writes. Below is an example of such implementation where two policy registers are defined for each of these actions. The policy is defined such that: the AES-key registers can only be read or used by a crypto agent with identity "1" when bit #1 is set. The AES-key registers can only be programmed by a trusted firmware with identity "2" when bit #2 is set.

Good

AES_KEY_READ_POLICY
                                [31:0] Default 0x00000002 - meaning only Crypto engine with identity "1" can read registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3
                            
                            
                                AES_KEY_WRITE_POLICY
                                [31:0] Default 0x00000004 - meaning only trusted firmware with identity "2" can program registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3

Within the AXI node interface wrapper module in the RISC-V AXI module of the HACK@DAC'19 CVA6 SoC [REF-1346], an access control mechanism is employed to regulate the access of different privileged users to peripherals.

The AXI ensures that only users with appropriate privileges can access specific peripherals. For instance, a ROM module is accessible exclusively with Machine privilege, and AXI enforces that users attempting to read data from the ROM must possess machine privilege; otherwise, access to the ROM is denied. The access control information and configurations are stored in a ROM.

Bad

...
                            for (i=0; i<NB_SUBORDINATE; i++)
                            begin
                                for (j=0; j<NB_MANAGER; j++)
                                begin
                                    assign connectivity_map_o[i][j] = access_ctrl_i[i][j][priv_lvl_i] || ((j==6) && access_ctrl_i[i][7][priv_lvl_i]);
                            end
                        end
                        ...

However, in the example code above, while assigning distinct privileges to AXI manager and subordinates, both the Platform-Level Interrupt Controller Specification (PLIC) and the Core-local Interrupt Controller (CLINT) (which are peripheral numbers 6 and 7 respectively) utilize the same access control configuration. This common configuration diminishes the granularity of the AXI access control mechanism.

In certain situations, it might be necessary to grant higher privileges for accessing the PLIC than those required for accessing the CLINT. Unfortunately, this differentiation is overlooked, allowing an attacker to access the PLIC with lower privileges than intended.

As a consequence, unprivileged code can read and write to the PLIC even when it was not intended to do so. In the worst-case scenario, the attacker could manipulate interrupt priorities, potentially modifying the system's behavior or availability.

To address the aforementioned vulnerability, developers must enhance the AXI access control granularity by implementing distinct access control entries for the Platform-Level Interrupt Controller (PLIC) and the Core-local Interrupt Controller (CLINT). By doing so, different privilege levels can be defined for accessing PLIC and CLINT, effectively thwarting the potential attacks previously highlighted. This approach ensures a more robust and secure system, safeguarding against unauthorized access and manipulation of interrupt priorities. [REF-1347]

Good

...
                            for (i=0; i<NB_SUBORDINATE; i++)
                            begin
                                for (j=0; j<NB_MANAGER; j++)
                                begin
                                    assign connectivity_map_o[i][j] = access_ctrl_i[i][j][priv_lvl_i];
                            end
                        end
                        ...

Mitigations & Prevention

Architecture and DesignImplementationTesting High

Real-World CVE Examples

CVE ID	Description
CVE-2022-24985	A form hosting website only checks the session authentication status for a single form, making it possible to bypass authentication when there are multiple forms
CVE-2021-36934	An operating system has an overly permission Access Control List onsome system files, including those related to user passwords

Frequently Asked Questions

What is CWE-1220?

CWE-1220 (Insufficient Granularity of Access Control) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, impl...

How can CWE-1220 be exploited?

Attackers can exploit CWE-1220 (Insufficient Granularity of Access Control) to modify memory, read memory, execute unauthorized code or commands, gain privileges or assume identity, bypass protection mechanism, other. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.

How do I prevent CWE-1220?

Key mitigations include:

What is the severity of CWE-1220?

CWE-1220 is classified as a Base-level weakness (Medium abstraction). It has been observed in 2 real-world CVEs.