CWE-1267: Policy Uses Obsolete Encoding

Description

The product uses an obsolete encoding mechanism to implement access controls.

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.

Potential Impact

Confidentiality, Integrity, Availability, Access Control

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

Demonstrative Examples

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.

Bad

If (Bus_transaction[14] == "1")Trusted = "1"ElseTrusted = "0"
        If (trusted)Allow access to AES-Key registersElseDeny access to AES-Key registers

Good

Security_Token[4:0] = Bus_transaction[15:11]
        If (AES_KEY_ACCESS_POLICY[Security_Token] == "1")Allow access to AES-Key registersElseDeny access to AES-Key registers

Mitigations & Prevention

Architecture and DesignImplementation High

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.

Frequently Asked Questions

What is CWE-1267?

CWE-1267 (Policy Uses Obsolete Encoding) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product uses an obsolete encoding mechanism to implement access controls.

How can CWE-1267 be exploited?

Attackers can exploit CWE-1267 (Policy Uses Obsolete Encoding) to 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. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.

How do I prevent CWE-1267?

Key mitigations include: 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.

What is the severity of CWE-1267?

CWE-1267 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.