Détail du CWE-1326

CWE-1326

Missing Immutable Root of Trust in Hardware
Draft
2020-12-10
00h00 +00:00
2023-10-26
00h00 +00:00
Notifications pour un CWE
Restez informé de toutes modifications pour un CWE spécifique.
Gestion des notifications

Nom: Missing Immutable Root of Trust in Hardware

A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.

Description du CWE

A System-on-Chip (SoC) implements secure boot by verifying or authenticating signed boot code. The signing of the code is achieved by an entity that the SoC trusts. Before executing the boot code, the SoC verifies that the code or the public key with which the code has been signed has not been tampered with. The other data upon which the SoC depends are system-hardware settings in fuses such as whether "Secure Boot is enabled". These data play a crucial role in establishing a Root of Trust (RoT) to execute secure-boot flows.

One of the many ways RoT is achieved is by storing the code and data in memory or fuses. This memory should be immutable, i.e., once the RoT is programmed/provisioned in memory, that memory should be locked and prevented from further programming or writes. If the memory contents (i.e., RoT) are mutable, then an adversary can modify the RoT to execute their choice of code, resulting in a compromised secure boot.

Note that, for components like ROM, secure patching/update features should be supported to allow authenticated and authorized updates in the field.

Informations générales

Modes d'introduction

Architecture and Design
Implementation : Such issues could be introduced during policy definition, hardware architecture, design, manufacturing, and/or provisioning. They can be identified later during testing or system configuration phases.

Plateformes applicables

Langue

Class: Not Language-Specific (Undetermined)

Systèmes d’exploitation

Class: Not OS-Specific (Undetermined)

Architectures

Class: Not Architecture-Specific (Undetermined)

Technologies

Name: Security Hardware (Undetermined)
Class: Not Technology-Specific (Undetermined)

Conséquences courantes

Portée Impact Probabilité
Authentication
Authorization
Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, Modify MemoryHigh

Mesures d’atténuation potentielles

Phases : Architecture and Design
When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes.
Phases : Implementation
During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes.

Méthodes de détection

Automated Dynamic Analysis

Automated testing can verify that RoT components are immutable.
Efficacité : High

Architecture or Design Review

Root of trust elements and memory should be part of architecture and design reviews.
Efficacité : High

Notes de cartographie des vulnérabilités

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Commentaire : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Modèles d'attaque associés

CAPEC-ID Nom du modèle d'attaque
CAPEC-679 Exploitation of Improperly Configured or Implemented Memory Protections

An adversary takes advantage of missing or incorrectly configured access control within memory to read/write data or inject malicious code into said memory.

CAPEC-68 Subvert Code-signing Facilities
Many languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment. Subverting this mechanism can be instrumental in an attacker escalating privilege. Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack.

Références

REF-1152

TCG Roots of Trust Specification
Trusted Computing Group.
https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf

REF-1153

Root of Trust Definitions and Requirements
GlobalPlatform Security Task Force.
https://globalplatform.org/wp-content/uploads/2018/06/GP_RoT_Definitions_and_Requirements_v1.0.1_PublicRelease_CC.pdf

REF-1348

bootrom.sv
https://github.com/HACK-EVENT/hackatdac19/blob/619e9fb0ef32ee1e01ad76b8732a156572c65700/bootrom/bootrom.sv#L263C19-L263C19

REF-1349

bootrom.sv
https://github.com/HACK-EVENT/hackatdac19/blob/ba6abf58586b2bf4401e9f4d46e3f084c664ff88/bootrom/bootrom.sv#L259C9-L259C9

Soumission

Nom Organisation Date Date de publication Version
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna Intel Corporation 2020-04-25 +00:00 2020-12-10 +00:00 4.3

Modifications

Nom Organisation Date Commentaire
CWE Content Team MITRE 2021-10-28 +00:00 updated Demonstrative_Examples
CWE Content Team MITRE 2022-04-28 +00:00 updated Applicable_Platforms, Related_Attack_Patterns
CWE Content Team MITRE 2022-06-28 +00:00 updated Applicable_Platforms, Modes_of_Introduction
CWE Content Team MITRE 2023-04-27 +00:00 updated Relationships
CWE Content Team MITRE 2023-06-29 +00:00 updated Mapping_Notes
CWE Content Team MITRE 2023-10-26 +00:00 updated Demonstrative_Examples, References