Common Weakness Enumeration

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

This 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.

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Example 1

Consider a product that stores a 128-bit AES key in four 32-bit registers, collectively called the AES key registers.

Three additional 32-bit registers are used to define the hardware enforced access control for the AES key registers. Collectively these registers are referred to as the AES Policy registers, and their functions are explained in the following table:

Each AES policy register uses one bit per agent to specify whether that agent has the permission defined by the register. Bit 0 corresponds to Agent 0, bit 1 to Agent 1, and so on. A value of 1 grants permission; 0 denies it. For example, setting bit 0 of AES_KEY_READ_POLICY to 1 allows Agent 0 to read the AES key registers.

The following initial configuration for the AES policy registers illustrates these permissions for four agents, numbered 0 through 3. The table shows only bits 3 through 0, with bit 0 on the right. All higher bits are 0.

Agents 0, 1, and 3 are trusted. Agent 2 is untrusted and should not have access to the AES key or its access policies. The initial values of the three AES policy registers shown above result in the permissions summarized below.

The initial configuration denies untrusted Agent 2 direct access to the AES key but allows it to modify the policies that enforce this restriction.

For example, Agent 2 can change AES_KEY_WRITE_POLICY from its initial value of 0x00000002 (0010b) to 0x00000006 (0110b). This sets bit 2 while preserving bit 1, granting Agent 2 write access to the AES key registers while retaining Agent 1’s write access.

To prevent this, grant permission to modify the access policies only to agents trusted to manage access to the key. Setting the initial value of AES_KEY_CONTROL_POLICY to 0x00000008 (1000b) allows only trusted Agent 3 to write to AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY. Untrusted Agent 2 can no longer modify either policy to grant itself access to the AES key registers. The initial policy register values should therefore be as follows:

This 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.