CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (4.0)  
ID

CWE-1243: Exposure of Security-Sensitive Fuse Values During Debug

Weakness ID: 1243
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product exposes security-sensitive values stored in fuses during debug.
+ Extended Description

Several security-sensitive values are blown as fuses in a chip to be used during early-boot flows or later at runtime. Examples of these security-sensitive values include root keys, encryption keys, manufacturing-specific information, chip-manufacturer-specific information, and original-equipment-manufacturer (OEM) data. After the chip is powered on, these values are sensed from fuses and stored in temporary locations such as registers and local memories. These locations are typically access-control protected from untrusted agents capable of accessing them. Even to trusted agents, only read-access is provided. However, these locations are not blocked during debug flows, allowing an untrusted debugger to access these assets and compromise system security.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.200Exposure of Sensitive Information to an Unauthorized Actor
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Modify Memory; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Secret manufacturing data (such as die information) are stored in fuses. While the chip powers on, this value is sensed from fuses and is stored in a microarchitectural register. This register is only given read access to trusted software running on the core. Untrusted software running on the core cannot access it.

(bad code)
Example Language: Other 
All microarchitectural registers in this chip can be accessed through the debug interface. As a result, even an untrusted debugger can access this data and get hold of secret manufacturing data.
(informative)
 
Registers used to store security-sensitive values sensed from fuses should be blocked on debug. They should be disconnected from the debug interface.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

When in debug mode, disable access to security-sensitive values sensed from fuses and stored in temporary locations.

+ Content History
Submissions
Submission DateSubmitterOrganization
2020-02-12Arun KanuparthiIntel Corporation
More information is available — Please select a different filter.
Page Last Updated: February 19, 2020