Policy Privileges are not Assigned Consistently Between Control and Data Agents

The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.


Description

Integrated circuits and hardware engines may provide access to resources (device-configuration, encryption keys, etc.) belonging to trusted firmware or software modules (commonly set by a BIOS or a bootloader). These accesses are typically controlled and limited by the hardware. Hardware design access control is sometimes implemented using a policy. A policy defines which entity or agent may or may not be allowed to perform an action. When a system implements multiple levels of policies, a control policy may allow direct access to a resource as well as changes to the policies themselves.

Resources that include agents in their control policy but not in their write policy could unintentionally allow an untrusted agent to insert itself in the write policy register. Inclusion in the write policy register could allow a malicious or misbehaving agent write access to resources. This action could result in security compromises including leaked information, leaked encryption keys, or modification of device configuration.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

Consider a system with a register for storing an AES key for encryption or decryption. The key is composed of 128 bits implemented as a set of four 32-bit registers. The key registers are resources and registers, AES_KEY_CONTROL_POLICY, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary, access controls.

The control-policy register defines which agents can write to the read-policy and write-policy registers. 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 32-bit register 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.

RegisterField descriptionAES_ENC_DEC_KEY_0AES key [0:31] for encryption or decryption
Default 0x00000000AES_ENC_DEC_KEY_1AES key [32:63] for encryption or decryption
Default 0x00000000AES_ENC_DEC_KEY_2AES key [64:95] for encryption or decryption
Default 0x00000000AES_ENC_DEC_KEY_3AES key [96:127] for encryption or decryption
Default 0x00000000AES_KEY_CONTROL_POLICY[31:0] Default 0x00000018, meaning agent with identities "4" and "3" has read/write access to this register (i.e., AES_KEY_CONTROL_POLICY), AES_KEY_READ_POLICY, and AES_KEY_WRITE_POLICY registersAES_KEY_READ_POLICY[31:0] Default 0x00000002, agent with identity "1" can only read AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registersAES_KEY_WRITE_POLICY[31:0] Default 0x00000004, agent with identity "2" can only write to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers

In the above example, the AES_KEY_CONTROL_POLICY register has agents with identities "4"and "3" in its policy. Assuming the agent with identity "4" is trusted and the agent with identity "3" is untrusted. The untrusted agent "3" can write to AES_KEY_WRITE_POLICY with a value of 0x0000000C thus allowing write access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers.

The AES_KEY_CONTROL_POLICY defines which agents have write access to the AES_KEY_CONTROL_POLICY, AES_KEY_READ_POLICY, and the AES_KEY_WRITE_POLICY registers,

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.

For the above example, the control, read-and-write-policy registers’ values are defined as below.

RegisterField descriptionAES_KEY_CONTROL_POLICY[31:0] Default 0x00000010, meaning only agents with an identity of "4" have read/write access to this register (i.e., AES_KEY_CONTROL_POLICY), AES_KEY_READ_POLICY, and AES_KEY_WRITE_POLICY registersAES_KEY_READ_POLICY[31:0] Default 0x00000002, meaning only trusted firmware with an identity of "1" can program registers: 
AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3AES_KEY_WRITE_POLICY[31:0] Default 0x00000004, meaning only trusted firmware with an identity of "2" can program registers: 
AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3

See Also

Privilege Separation and Access Control Issues

Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of s...

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses without Software Fault Patterns

CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.