The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
View on MITREIntegrated 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.
Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing.
No detection method information available for this CWE.
No examples or observed CVEs available for this CWE.
No relationship information available for this CWE.
CWE-1268: Policy Privileges are not Assigned Consistently Between Control and Data Agents is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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.
If exploited, CWE-1268 (Policy Privileges are not Assigned Consistently Between Control and Data Agents) it can compromise Confidentiality, Integrity, Availability and Access Control, leading to outcomes such as Modify Memory, Read Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity and Bypass Protection Mechanism.
Recommended mitigations for CWE-1268 include: Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing.
CWE-1268 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
A CWE (Common Weakness Enumeration) like CWE-1268 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.