CWE-1259 applies to a system on a chip that uses security tokens to decide which actions an agent may take, where those tokens are not properly protected. SoC architects and verification teams are the audience.
How it happens
SoCs give a token to every agent that can generate or receive an action. The actions include read, write, program, reset, fetch and compute. An agent can hold several tokens, unique to its trust level or privileges. The tokens are how the system tells which agent did what, so the security of the SoC depends on them.
MITRE names the common failure: improperly restricting the assignment of tokens to trusted components. If an untrusted component can get or change a token, it can act with someone else's rights.
The entry's example is an AES key held in four 32-bit registers, with a control register named AES_KEY_ACCESS_POLICY. Each bit of that register stands for a token, up to 32 in all. A set bit lets the agent with that token number act on the key registers. The system has two agents, a main controller with token 1 and an auxiliary controller with token 2, and the default policy admits only one of them.
What an attacker gains
The record lists confidentiality, integrity and availability with high impact: modifying files and memory, executing unauthorized code or commands, bypassing protection mechanisms, gaining privileges or assuming identity, and crashing the system.
How to find it
The record lists no detection methods. See the mitigation below for the testing MITRE suggests.
How to fix it
MITRE recommends, at design and implementation, a security token assignment review that checks for design inconsistency and common weaknesses. The token definition and programming flow should be tested in both pre-silicon and post-silicon testing.
Quick check
What is the usual flaw?
Assignment of security tokens is not restricted to trusted components, so untrusted agents can obtain or change tokens.
When should tokens be tested?
Both before and after silicon exists, per MITRE.
