The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Memory
Access Control: Bypass Protection Mechanism
Phase: Architecture and Design
Description:
The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.
Systems-On-A-Chip (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify which actions originated from which agent. These actions may be one of the directives: ‘read’, ‘write’, ‘program’, ‘reset’, ‘fetch’, ‘compute’, etc. Security Tokens are assigned to every agent in the System that is capable of generating an action or receiving an action from another agent. Multiple Security Tokens may be assigned to an agent and may be unique based on the agent’s trust level or allowed privileges. Since the Security Tokens are integral for the maintenence of security in an SoC, they need to be protected properly. A common weakness afflicting Security Tokens is improperly restricting the assignment to trusted components. Consequently, an improperly protected Security Token may be able to be programmed by a malicious agent (i.e., the Security Token is mutable) to spoof the action as if it originated from a trusted agent.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Availability, Access Control: Modify Files or Directories, Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Gain Privileges or Assume Identity, Modify Memory, Modify Memory, DoS: Crash, Exit, or Restart
Phase: Architecture and Design, Implementation
Description:
The software reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
This typically occurs when the pointer or its index is incremented to a position beyond the bounds of the buffer or when pointer arithmetic results in a position outside of the valid memory location to name a few. This may result in exposure of sensitive information or possibly a crash.
Modes of Introduction:
– Implementation
Confidentiality: Read Memory
Confidentiality: Bypass Protection Mechanism
By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Availability: Modify Memory, Read Memory, DoS: Instability
Phase: Architecture and Design
Description:
Phase: Implementation
Effectiveness: High
Description:
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
Modes of Introduction:
– Architecture and Design
Availability, Access Control: DoS: Crash, Exit, or Restart, DoS: Instability, Gain Privileges or Assume Identity, Bypass Protection Mechanism
Phase: Architecture and Design
Description:
Phase: Architecture and Design
Description:
The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity: Read Memory, Read Application Data, Modify Memory, Modify Application Data, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Unexpected State, Alter Execution Logic
Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.
Phase: Architecture and Design
Description:
Design proper policies for hardware register access from software.
Phase: Implementation
Description:
Ensure that access control policies for register access are implemented in accordance with the specified design.
The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.
Sections of a product intended to have restricted access may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Access Control: Varies by Context
Phase: Architecture and Design
Description:
Specific protection requirements depend strongly on contextual factors including the level of acceptable risk associated with compromise to the product’s protection mechanism. Designers could incorporate anti-tampering measures that protect against or detect when the product has been tampered with.
Phase: Testing
Description:
The testing phase of the lifecycle should establish a method for determining whether the protection mechanism is sufficient to prevent unauthorized access.
Phase: Manufacturing
Description:
Ensure that all protection mechanisms are fully activated at the time of manufacturing and distribution.
The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Memory, Read Application Data
Phase: Architecture and Design
Description:
During execution of non-reentrant code, the software performs a call that unintentionally produces a nested invocation of the non-reentrant code.
In complex software, a single function call may lead to many different possible code paths, some of which may involve deeply nested calls. It may be difficult to foresee all possible code paths that could emanate from a given function call. In some systems, an external actor can manipulate inputs to the system and thereby achieve a wide range of possible control flows. This is frequently of concern in software that executes script from untrusted sources. Examples of such software are web browsers and PDF readers. A weakness is present when one of the possible code paths resulting from a function call alters program state that the original caller assumes to be unchanged during the call.
Modes of Introduction:
Integrity: Unexpected State
Exploitation of this weakness can leave the application in an unexpected state and cause variables to be reassigned before the first invocation has completed. This may eventually result in memory corruption or unexpected code execution.
Phase: Architecture and Design
Effectiveness: High
Description:
When architecting a system that will execute untrusted code in response to events, consider executing the untrusted event handlers asynchronously (asynchronous message passing) as opposed to executing them synchronously at the time each event fires. The untrusted code should execute at the start of the next iteration of the thread’s message loop. In this way, calls into non-reentrant code are strictly serialized, so that each operation completes fully before the next operation begins. Special attention must be paid to all places where type coercion may result in script execution. Performing all needed coercions at the very beginning of an operation can help reduce the chance of operations executing at unexpected junctures.
Phase: Implementation
Effectiveness: High
Description:
Make sure the code (e.g., function or class) in question is reentrant by not leveraging non-local data, not modifying its own code, and not calling other non-reentrant code.
The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned. A scrubbing capability could be missing, insufficient, or incorrect.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Memory
Phase: Architecture and Design
Description:
Phase: Policy
Description:
Phase: Implementation
Description: