CAPEC-681: Exploitation of Improperly Controlled Hardware Security Identifiers

A System-on-Chip (SoC) often implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, these mechanisms may be exploitable due to any number of the following: The security identifiers are missing The security identifiers are incorrectly implemented or generated The security identifiers are generated with an obsolete encoding The security identifiers are generated and implemented correctly, but are improperly protected If the security identifiers leveraged by the SoC are missing or misconfigured, an adversary may be able to take advantage of this shortcoming to circumvent the intended access controls. This could result in the adversary gaining unintended access, performing a Denial of Service (DoS), escalating privileges, or spoofing actions from a trusted agent.

A system contains a register (divided into four 32-bit registers) that is used to store a 128-bit AES key for encryption/decryption, in addition to an access-policy register. The access-policy register determines which agents may access the AES-key registers, based on a corresponding security identifier. It is assumed the system has two agents: a Main-controller and an Aux-controller, with respective security identifiers "1" and "2". The Main-controller (ID "1") is meant to have access to the AES-key registers, while the Aux-controller (ID "2") has access to the access-policy register. If a SoC incorrectly generates security identifier "1" for both agents, then both agents will have access to the AES-key registers. This could further result in a Denial-of-Service (DoS) or the execution of an action that in turn could result in privilege escalation or unintended access.