CWE-1267: Policy Uses Obsolete Encoding
The product uses an obsolete encoding mechanism to implement access controls.
Last updated
Overview
Within a System-On-a-Chip (SoC), various circuits and hardware engines generate transactions for the purpose of accessing (read/write) assets or performing various actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (identifying the originator of the transaction) and a destination identity (routing the transaction to the respective entity). Sometimes the transactions are qualified with a Security Token. This Security Token helps the destination agent decide on the set of allowed actions (e.g., access to an asset for reads and writes). A policy encoder is used to map the bus transactions to Security Tokens that in turn are used as access-controls/protection mechanisms. A common weakness involves using an encoding which is no longer trusted, i.e., an obsolete encoding.
Common consequences
What can happen when CWE-1267 is exploited.
Modify Memory, Read Memory, Modify Files or Directories, Read Files or Directories, DoS: Resource Consumption (Other), Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Reduce Reliability
Affects: Confidentiality, Integrity, Availability, Access Control
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-1267, grouped by where in the lifecycle they apply.
Security Token Decoders should be reviewed for design inconsistency and common weaknesses.
Access and programming flows should be tested in both pre-silicon and post-silicon testing.
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
For example, consider a system that has four bus masters. The table below provides bus masters, their Security Tokens, and trust assumptions.
The policy encoding is to be defined such that Security Token will be used in implemented access-controls. The bits in the bus transaction that contain Security-Token information are Bus_transaction [15:11]. The assets are the AES-Key registers for encryption or decryption. The key of 128 bits is implemented as a set of four, 32-bit registers.
Below is an example of a policy encoding scheme inherited from a previous project where all "ODD" numbered Security Tokens are trusted.
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-1267.
- What is CWE-1267?
- The product uses an obsolete encoding mechanism to implement access controls.
- How do you prevent CWE-1267?
- Security Token Decoders should be reviewed for design inconsistency and common weaknesses.
- What are the consequences of CWE-1267?
- Exploiting CWE-1267 can lead to: Modify Memory, Read Memory, Modify Files or Directories, Read Files or Directories, DoS: Resource Consumption (Other), Execute Unauthorized Code or Commands.
References
- MITRE CWE definition (CWE-1267) (opens in a new tab)
- CWE-1267 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-1267
Get alerted the moment a new CWE-1267 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.