Description
The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
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.
Potential Impact
Confidentiality, Integrity, Availability, Access Control
Modify Memory, Read Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Files or Directories, Reduce Reliability
Demonstrative Examples
RegisterField description
AES_KEY_CONTROL_POLICYControls which agents can write to READ_POLICY and WRITE_POLICY registers[31:0] Default 0x00000018
AES_KEY_READ_POLICYControls which agents can read the AES-key registers[31:0] Default 0x00000002
AES_KEY_WRITE_POLICYControls which agents can write to the AES-key registers[31:0] Default 0x00000004RegisterField description
AES_KEY_CONTROL_POLICY[31:0] Default 0x00000010
AES_KEY_READ_POLICY[31:0] Default 0x00000002
AES_KEY_WRITE_POLICY[31:0] Default 0x00000004Mitigations & Prevention
Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing.
Related Weaknesses
Frequently Asked Questions
What is CWE-1268?
CWE-1268 (Policy Privileges are not Assigned Consistently Between Control and Data Agents) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
How can CWE-1268 be exploited?
Attackers can exploit CWE-1268 (Policy Privileges are not Assigned Consistently Between Control and Data Agents) to modify memory, read memory, dos: crash, exit, or restart, execute unauthorized code or commands, gain privileges or assume identity, bypass protection mechanism, read files or directories, reduce reliability. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-1268?
Key mitigations include: Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing.
What is the severity of CWE-1268?
CWE-1268 is classified as a Base-level weakness (Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.