CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1343: Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List (4.6)  
ID

CWE VIEW: Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List

View ID: 1343
Type: Explicit
Status: Stable
Downloads: Booklet | CSV | XML
+ Objective
CWE entries in this view are listed in the 2021 CWE Most Important Hardware Weaknesses List, as determined by the Hardware CWE Special Interest Group (HW CWE SIG).
+ Audience
StakeholderDescription
Hardware DesignersBy following this list, hardware designers and implementers are able to significantly reduce the number of weaknesses that occur in their products.
Product CustomersCustomers can use the weaknesses in this view in order to formulate independent evidence of a claim by a product vendor to have eliminated / mitigated the most dangerous weaknesses.
EducatorsEducators can use this view to focus curriculum on the most important hardware weaknesses.
+ Membership
NatureTypeIDName
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1189Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1191On-Chip Debug and Test Interface With Improper Access Control
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1231Improper Prevention of Lock Bit Modification
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1233Security-Sensitive Hardware Controls with Missing Lock Bit Protection
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1240Use of a Cryptographic Primitive with a Risky Implementation
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1244Internal Asset Exposed to Unsafe Debug Access Level or State
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1256Improper Restriction of Software Interfaces to Hardware Features
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1260Improper Handling of Overlap Between Protected Memory Ranges
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1272Sensitive Information Uncleared Before Debug/Power State Transition
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1274Improper Access Control for Volatile Memory Containing Boot Code
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1277Firmware Not Updateable
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1300Improper Protection of Physical Side Channels
+ References
[REF-1238] MITRE. "2021 CWE Most Important Hardware Weaknesses". 2021-10-28. <https://cwe.mitre.org/scoring/lists/2021_CWE_MiHW.html>.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses12out of 924
Categories0out of 326
Views0out of 46
Total12out of1296
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2021-09-29CWE Content TeamMITRE

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-1277: Firmware Not Updateable

Weakness ID: 1277
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.
+ Extended Description
Without the ability to patch or update firmware, consumers will be left vulnerable to exploitation of any known vulnerabilities, or any vulnerabilities that are discovered in the future. This can expose consumers to permanent risk throughout the entire lifetime of the device, which could be years or decades. Some external protective measures and mitigations might be employed to aid in preventing or reducing the risk of malicious attack, but the root weakness cannot be corrected.
+ Relationships
Section HelpThis table 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
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1329Reliance on Component That is Not Updateable
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1310Missing Ability to Patch ROM Code
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction
Section HelpThe 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
RequirementsRequirements development might not consider the importance of updates over the lifetime of the product, or might not choose the ability due to concerns such as expense or speed to market.
Architecture and DesignLack of planning during architecture development and design, or external pressures such as speed to market, could ignore the capability to update.
ImplementationThe weakness can appear through oversight during implementation.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Integrity
Access Control
Authentication
Authorization

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism; Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart

If an attacker can identify an exploitable vulnerability in one device that has no means of patching, the attack may be used against an entire class of devices.
Medium
+ Demonstrative Examples

Example 1

A refrigerator has an Internet interface for the official purpose of alerting the manufacturer when that refrigerator detects a fault. Because the device is attached to the Internet, the refrigerator is a target for hackers who may wish to use the device other potentially more nefarious purposes.

(bad code)
Example Language: Other 
The refrigerator has no means of patching and is hacked becoming a spewer of email spam.
(good code)
Example Language: Other 
The device automatically patches itself and provides considerable more protection against being hacked.
+ Observed Examples
ReferenceDescription
Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are "end-of-support" and cannot be patched (CWE-1277). [REF-1097]
hardware "smart lock" has weak key generation, allowing attackers to steal the key by BLE sniffing, but the device's firmware cannot be upgraded [REF-1095].
+ Potential Mitigations

Phase: Requirements

Specify requirements to provide the ability to update the firmware.

Phase: Architecture and Design

Design the device to allow for updating the firmware.

Phase: Implementation

Implement the necessary functionality to allow the firmware to be updated.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Create a new installable boot image of the current build with a minor version number change. Use the standard installation method to update the boot image. Verify that the minor version number has changed. Create a fake image. Verify that the boot updater will not install the fake image and generates an invalid image error message.

Effectiveness: High

Architecture or Design Review

Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.

Effectiveness: Moderate

Manual Dynamic Analysis

Determine if there is a lack of a capability to update read-only memory structure. This could manifest as a difference between the latest firmware version and current version within the device.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Terminology

The "firmware" term does not have a single commonly-shared definition, so there may be variations in how this CWE entry is interpreted during mapping.
+ References
[REF-1095] Matthew Hughes. "Bad news: KeyWe Smart Lock is easily bypassed and can't be fixed". 2019-12-11. <https://www.theregister.com/2019/12/11/f_secure_keywe/>.
[REF-1096] Alex Scroxton. "Alarm bells ring, the IoT is listening". <https://www.computerweekly.com/news/252475324/Alarm-bells-ring-the-IoT-is-listening>.
[REF-1097] Brian Krebs. "Zyxel Flaw Powers New Mirai IoT Botnet Strain". 2020-03-20. <https://krebsonsecurity.com/2020/03/zxyel-flaw-powers-new-mirai-iot-botnet-strain/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-13Paul A. WortmanWells Fargo
+ Contributions
Contribution DateContributorOrganization
2021-10-12Paul A. WortmanWells Fargo
provided detection methods and observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Potential_Mitigations
2020-12-10CWE Content TeamMITRE
updated Description, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes

CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code

Weakness ID: 1274
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.
+ Extended Description

Adversaries could bypass the secure-boot process and execute their own untrusted, malicious boot code.

As a part of a secure-boot process, the read-only-memory (ROM) code for a System-on-Chip (SoC) or other system fetches bootloader code from Non-Volatile Memory (NVM) and stores the code in Volatile Memory (VM), such as dynamic, random-access memory (DRAM) or static, random-access memory (SRAM). The NVM is usually external to the SoC, while the VM is internal to the SoC. As the code is transferred from NVM to VM, it is authenticated by the SoC's ROM code.

If the volatile-memory-region protections or access controls are insufficient to prevent modifications from an adversary or untrusted agent, the secure boot may be bypassed or replaced with the execution of an adversary's code.

+ Relationships
Section HelpThis table 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
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction
Section HelpThe 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 DesignThis weakness can be introduced during hardware architecture or design but can be identified later during testing.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control
Integrity

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity

High
+ Demonstrative Examples

Example 1

A typical SoC secure boot's flow includes fetching the next piece of code (i.e., the boot loader) from NVM (e.g., serial, peripheral interface (SPI) flash), and transferring it to DRAM/SRAM volatile, internal memory, which is more efficient.

(bad code)
 
The volatile-memory protections or access controls are insufficient.

The memory from where the boot loader executes can be modified by an adversary.

(good code)
 
A good architecture should define appropriate protections or access controls to prevent modification by an adversary or untrusted agent, once the bootloader is authenticated.
+ Observed Examples
ReferenceDescription
Locked memory regions may be modified through other interfaces in a secure-boot-loader image due to improper access control.
+ Potential Mitigations

Phase: Architecture and Design

Ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code.

Phase: Testing

Test the volatile-memory protections to ensure they are safe from modification or untrusted code.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Ensure the volatile memory is lockable or has locks. Ensure the volatile memory is locked for writes from untrusted agents or adversaries. Try modifying the volatile memory from an untrusted agent, and ensure these writes are dropped.

Effectiveness: High

Manual Analysis

Analyze the device using the following steps:

  • 1) Identify all fabric master agents that are active during system Boot Flow when initial code is loaded from Non-volatile storage to volatile memory.
  • 2) Identify the volatile memory regions that are used for storing loaded system executable program.
  • 3) During system boot, test programming the identified memory regions in step 2 from all the masters identified in step 1.

Only trusted masters should be allowed to write to the memory regions. For example, pluggable device peripherals should not have write access to program load memory regions.

Effectiveness: Moderate

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-04-25Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
suggested content improvements
2021-10-22Hareesh KhattriIntel Corporation
provided detection method
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Related_Attack_Patterns

CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges

Weakness ID: 1260
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
+ Extended Description

Isolated memory regions and access control (read/write) policies are used by hardware to protect privileged software. Software components are often allowed to change or remap memory region definitions in order to enable flexible and dynamically changeable memory management by system software.

If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege, privilege escalation may be available to attackers. The memory protection unit (MPU) logic can incorrectly handle such an address overlap and allow the lower-privilege software to read or write into the protected memory region, resulting in privilege escalation attack. An address overlap weakness can also be used to launch a denial of service attack on the higher-privilege software memory regions.

+ Relationships
Section HelpThis table 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
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction
Section HelpThe 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 DesignSuch issues could be introduced during hardware architecture and design or implementation and identified later during the Testing phase.
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Memory IP (Undetermined Prevalence)

Processor IP (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Integrity
Availability

Technical Impact: Modify Memory; Read Memory; DoS: Instability

High
+ Demonstrative Examples

Example 1

For example, consider a design with a 16-bit address that has two software privilege levels: Privileged_SW and Non_privileged_SW. To isolate the system memory regions accessible by these two privilege levels, the design supports three memory regions: Region_0, Region_1, and Region_2.

Each region is defined by two 32 bit registers: its range and its access policy.

  • Address_range[15:0]: specifies the Base address of the region
  • Address_range[31:16]: specifies the size of the region
  • Access_policy[31:0]: specifies what types of software can access a region and which actions are allowed

Certain bits of the access policy are defined symbolically as follows:

  • Access_policy.read_np: if set to one, allows reads from Non_privileged_SW
  • Access_policy.write_np: if set to one, allows writes from Non_privileged_SW
  • Access_policy.execute_np: if set to one, allows code execution by Non_privileged_SW
  • Access_policy.read_p: if set to one, allows reads from Privileged_SW
  • Access_policy.write_p: if set to one, allows writes from Privileged_SW
  • Access_policy.execute_p: if set to one, allows code execution by Privileged_SW

For any requests from software, an address-protection filter checks the address range and access policies for each of the three regions, and only allows software access if all three filters allow access.

Consider the following goals for access control as intended by the designer:

  • Region_0 & Region_1: registers are programmable by Privileged_SW
  • Region_2: registers are programmable by Non_privileged_SW

The intention is that Non_privileged_SW cannot modify memory region and policies defined by Privileged_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privileged_SW is using.

(bad code)
 

Non_privileged_SW can program the Address_range register for Region_2 so that its address overlaps with the ranges defined by Region_0 or Region_1. Using this capability, it is possible for Non_privileged_SW to block any memory region from being accessed by Privileged_SW, i.e., Region_0 and Region_1.

This design could be improved in several ways.

(good code)
 
Ensure that software accesses to memory regions are only permitted if all three filters permit access. Additionally, the scheme could define a memory region priority to ensure that Region_2 (the memory region defined by Non_privileged_SW) cannot overlap Region_0 or Region_1 (which are used by Privileged_SW).
+ Observed Examples
ReferenceDescription
virtualization product allows compromise of hardware product by accessing certain remapping registers.
processor design flaw allows ring 0 code to access more privileged rings by causing a register window to overlap a range of protected system RAM [REF-1100]
+ Potential Mitigations

Phase: Architecture and Design

Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software.

Phase: Implementation

For all of the programmable memory protection regions, the memory protection unit (MPU) design can define a priority scheme.

For example: if three memory regions can be programmed (Region_0, Region_1, and Region_2), the design can enforce a priority scheme, such that, if a system address is within multiple regions, then the region with the lowest ID takes priority and the access-control policy of that region will be applied. In some MPU designs, the priority scheme can also be programmed by trusted software.

Hardware logic or trusted firmware can also check for region definitions and block programming of memory regions with overlapping addresses.

The memory-access-control-check filter can also be designed to apply a policy filter to all of the overlapping ranges, i.e., if an address is within Region_0 and Region_1, then access to this address is only granted if both Region_0 and Region_1 policies allow the access.

Effectiveness: High

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Manual Analysis

Create a high privilege memory block of any arbitrary size. Attempt to create a lower privilege memory block with an overlap of the high privilege memory block. If the creation attempt works, fix the hardware. Repeat the test.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Maintenance

As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.
+ References
[REF-1100] Christopher Domas. "The Memory Sinkhole". 2015-07-20. <https://github.com/xoreaxeaxeax/sinkhole/blob/master/us-15-Domas-TheMemorySinkhole-wp.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
suggested content improvements
2021-10-22Hareesh KhattriIntel Corporation
suggested observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Related_Attack_Patterns
2020-12-10CWE Content TeamMITRE
updated Maintenance_Notes

CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

Weakness ID: 1189
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
+ Extended Description

A System-On-a-Chip (SoC) has a lot of functionality, but it may have a limited number of pins or pads. A pin can only perform one function at a time. However, it can be configured to perform multiple different functions. This technique is called pin multiplexing. Similarly, several resources on the chip may be shared to multiplex and support different features or functions. When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access the assets intended to be accessed only by the trusted agents.

+ Relationships
Section HelpThis table 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.668Exposure of Resource to Wrong Sphere
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.653Improper Isolation or Compartmentalization
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1303Non-Transparent Sharing of Microarchitectural Resources
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1331Improper Isolation of Shared Resources in Network On Chip (NoC)
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1331Improper Isolation of Shared Resources in Network On Chip (NoC)
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows 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)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Bypass Protection Mechanism

If resources being used by a trusted user are shared with an untrusted user, the untrusted user may be able to modify the functionality of the shared resource of the trusted user.
Integrity

Technical Impact: Quality Degradation

The functionality of the shared resource may be intentionally degraded.
+ Demonstrative Examples

Example 1

Consider the following SoC design. The Hardware Root of Trust (HRoT) local SRAM is memory mapped in the core{0-N} address space. The HRoT allows or disallows access to private memory ranges, thus allowing the sram to function as a mailbox for communication between untrusted and trusted HRoT partitions.

Hardware Root of Trust

We assume that the threat is from malicious software in the untrusted domain. We assume this software has access to the core{0-N} memory map and can be running at any privilege level on the untrusted cores. The capability of this threat in this example is communication to and from the mailbox region of SRAM modulated by the hrot_iface. To address this threat, information must not enter or exit the shared region of SRAM through hrot_iface when in secure or privileged mode.

+ Observed Examples
ReferenceDescription
Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

When sharing resources, avoid mixing agents of varying trust levels.

Untrusted agents should not share resources with trusted agents.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

Kernel integrity verification can help identify when shared resource configuration settings have been modified.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ References
[REF-1036] Ali Abbasi and Majid Hashemi. "Ghost in the PLC Designing an Undetectable Programmable Logic Controller Rootkit via Pin Control Attack". 2016. <https://www.blackhat.com/docs/eu-16/materials/eu-16-Abbasi-Ghost-In-The-PLC-Designing-An-Undetectable-Programmable-Logic-Controller-Rootkit-wp.pdf>.
[REF-1138] Stewart Smith. "CVE-2019-6260: Gaining control of BMC from the host processor". 2019. <https://www.flamingspork.com/blog/2019/01/23/cve-2019-6260:-gaining-control-of-bmc-from-the-host-processor/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-07-16Tortuga Logic
Provided Demonstrative Example for Hardware Root of Trust
2021-10-22Hareesh KhattriIntel Corporation
provided observed example
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Improper Isolation of Shared Resources on System-on-Chip (SoC)

CWE-1231: Improper Prevention of Lock Bit Modification

Weakness ID: 1231
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.
+ Extended Description

In integrated circuits and hardware intellectual property (IP) cores, device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification.

This behavior is commonly implemented using a trusted lock bit. When set, the lock bit disables writes to a protected set of registers or address regions. Design or coding errors in the implementation of the lock bit protection feature may allow the lock bit to be modified or cleared by software after it has been set. Attackers might be able to unlock the system and features that the bit is intended to protect.

+ Relationships
Section HelpThis table 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
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction
Section HelpThe 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 DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Modify Memory

Registers protected by lock bit can be modified even when lock is set.
High
+ Demonstrative Examples

Example 1

Consider the example design below for a digital thermal sensor that detects overheating of the silicon and triggers system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by firmware, and then the register needs to be locked (TEMP_SENSOR_LOCK).

(bad code)
Example Language: Other 
Register Field description
CRITICAL_TEMP_LIMIT [31:8] Reserved field; Read only; Default 0

[7:0] Critical temp 0-255 Centigrade; Read-write-lock; Default 125
TEMP_SENSOR_CALIB [31:0] Thermal sensor calibration data. Slope value used to map sensor reading to degrees Centigrade.
TEMP_SENSOR_LOCK [31:1] Reserved field; Read only; Default 0

[0] Lock bit, locks CRITICAL_TEMP_LIMIT and TEMP_SENSOR_CALIB registers; Write-1-once; Default 0
TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0

[1] Enable hardware shutdown on critical temperature detection; Read-write; Default 0
CURRENT_TEMP [31:8] Reserved field; Read only; Default 0

[7:0] Current Temp 0-255 Centigrade; Read-only; Default 0

In this example, note that if the system heats to critical temperature, the response of the system is controlled by the TEMP_HW_SHUTDOWN bit [1], which is not lockable. Thus, the intended security property of the critical temperature sensor cannot be fully protected, since software can misconfigure the TEMP_HW_SHUTDOWN register even after the lock bit is set to disable the shutdown response.

(good code)
 

To fix this weakness, one could change the TEMP_HW_SHUTDOWN field to be locked by TEMP_SENSOR_LOCK.

TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0

[1] Enable hardware shutdown on critical temperature detection; Read-write-Lock; Default 0

[0] Locked by TEMP_SENSOR_LOCK
+ Observed Examples
ReferenceDescription
chip reset clears critical read/write lock permissions for RSA function
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security lock bit protections must be reviewed for design inconsistency and common weaknesses.
  • Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.

Effectiveness: High

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Set the lock bit. Power cycle the device. Attempt to clear the lock bit. If the information is changed, implement a design fix. Retest. Also, attempt to indirectly clear the lock bit or bypass it.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
reviewed content changes
2021-10-22Hareesh KhattriIntel Corporation
provided observed example
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-1300: Improper Protection of Physical Side Channels

Weakness ID: 1300
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.
+ Extended Description

An adversary could monitor and measure physical phenomena to detect patterns and make inferences, even if it is not possible to extract the information in the digital domain.

Physical side channels have been well-studied for decades in the context of breaking implementations of cryptographic algorithms or other attacks against security features. These side channels may be easily observed by an adversary with physical access to the device, or using a tool that is in close proximity. If the adversary can monitor hardware operation and correlate its data processing with power, EME, and acoustic measurements, the adversary might be able to recover of secret keys and data.

+ Relationships
Section HelpThis table 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
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.203Observable Discrepancy
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.1255Comparison Logic is Vulnerable to Power Side-Channel Attacks
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.203Observable Discrepancy
+ Modes Of Introduction
Section HelpThe 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
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Read Memory; Read Application Data

+ Demonstrative Examples

Example 1

Consider a device that checks a passcode to unlock the screen.

(bad code)
 
As each character of the PIN number is entered, a correct character exhibits one current pulse shape while an incorrect character exhibits a different current pulse shape.

PIN numbers used to unlock a cell phone should not exhibit any characteristics about themselves. This creates a side channel. An attacker could monitor the pulses using an oscilloscope or other method. Once the first character is correctly guessed (based on the oscilloscope readings), they can then move to the next character, which is much more efficient than the brute force method of guessing every possible sequence of characters.

(good code)
 
Rather than comparing each character to the correct PIN value as it is entered, the device could accumulate the PIN in a register, and do the comparison all at once at the end. Alternatively, the components for the comparison could be modified so that the current pulse shape is the same regardless of the correctness of the entered character.

Example 2

Consider the device vulnerability CVE-2021-3011, which affects certain microcontrollers [REF-1221]. The Google Titan Security Key is used for two-factor authentication using cryptographic algorithms. The device uses an internal secret key for this purpose and exchanges information based on this key for the authentication. If this internal secret key and the encryption algorithm were known to an adversary, the key function could be duplicated, allowing the adversary to masquerade as the legitimate user.

(bad code)
 
The local method of extracting the secret key consists of plugging the key into a USB port and using electromagnetic (EM) sniffing tools and computers.
(good code)
 
Several solutions could have been considered by the manufacturer. For example, the manufacturer could shield the circuitry in the key or add randomized delays, indirect calculations with random values involved, or randomly ordered calculations to make extraction much more difficult or a combination of these techniques.
+ Observed Examples
ReferenceDescription
electromagnetic-wave side-channel in security-related microcontrollers allows extraction of private key
message encryption software uses certain instruction sequences that allows RSA key extraction using a chosen-ciphertext attack and acoustic cryptanalysis
virtualization product allows recovery of AES keys from the guest OS using a side channel attack against a power/energy monitoring interface.
power consumption varies based on number of pixels being illuminated in a display, allowing reading of secrets such as the PIN by using the USB interface to measure power consumption
+ Potential Mitigations

Phase: Architecture and Design

Apply blinding or masking techniques to implementations of cryptographic algorithms.

Phase: Implementation

Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side-channel.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Manual Analysis

Perform a set of leakage detection tests such as the procedure outlined in the Test Vector Leakage Assessment (TVLA) test requirements for AES [REF-1230]. TVLA is the basis for the ISO standard 17825 [REF-1229]. A separate methodology is provided by [REF-1228]. Note that sole reliance on this method might not yield expected results [REF-1239] [REF-1240].

Effectiveness: Moderate

Manual Analysis

Post-silicon, perform full side-channel attacks (penetration testing) covering as many known leakage models as possible against test code.

Effectiveness: Moderate

Manual Analysis

Pre-silicon - while the aforementioned TVLA methods can be performed post-silicon, models of device power consumption or other physical emanations can be built from information present at various stages of the hardware design process before fabrication. TVLA or known side-channel attacks can be applied to these simulated traces and countermeasures applied before tape-out. Academic research in this field includes [REF-1231] [REF-1232] [REF-1233].

Effectiveness: Moderate

+ Functional Areas
  • Power
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ References
[REF-1117] Paul Kocher, Joshua Jaffe and Benjamin Jun. "Introduction to differential power analysis and related attacks". 1998. <https://www.rambus.com/wp-content/uploads/2015/08/DPATechInfo.pdf>.
[REF-1118] Dakshi Agrawal, Bruce Archambeault, Josyula R. Rao and Pankaj Rohatgi. "The EM Side-Channel(s)". 2007-08-24. <https://link.springer.com/content/pdf/10.1007%2F3-540-36400-5_4.pdf>.
[REF-1119] Daniel Genkin, Adi Shamir and Eran Tromer. "RSA key extraction via low-bandwidth acoustic cryptanalysis". 2014-06-13. <https://www.iacr.org/archive/crypto2014/86160149/86160149.pdf>.
[REF-1120] Colin O’Flynn. "Power Analysis for Cheapskates". 2013-01-24. <https://media.blackhat.com/eu-13/briefings/OFlynn/bh-eu-13-for-cheapstakes-oflynn-wp.pdf>.
[REF-1055] Peter Gutmann. "Data Remanence in Semiconductor Devices". 10th USENIX Security Symposium. 2001-08. <https://www.usenix.org/legacy/events/sec01/full_papers/gutmann/gutmann.pdf>.
[REF-1218] Graham Cluley. "This Black Box Can Brute Force Crack iPhone PIN Passcodes". The Mac Security Blog. 2015-03-16. <https://www.intego.com/mac-security-blog/iphone-pin-pass-code/>.
[REF-1221] Victor Lomne and Thomas Roche. "A Side Journey to Titan". 2021-01-07. <https://ninjalab.io/wp-content/uploads/2021/01/a_side_journey_to_titan.pdf>.
[REF-1228] Gilbert Goodwill, Benjamin Jun, Josh Jaffe and Pankaj Rohatgi. "A testing methodology for side-channel resistance validation". 2011. <https://csrc.nist.gov/csrc/media/events/non-invasive-attack-testing-workshop/documents/08_goodwill.pdf>.
[REF-1229] ISO/IEC. "ISO/IEC 17825:2016: Testing methods for the mitigation of non-invasive attack classes against cryptographic modules". 2016. <https://www.iso.org/standard/60612.html>.
[REF-1230] Cryptography Research Inc.. "Test Vector Leakage Assessment (TVLA) Derived Test Requirements (DTR) with AES". 2015-08. <https://www.rambus.com/wp-content/uploads/2015/08/TVLA-DTR-with-AES.pdf>.
[REF-1231] Danilo Šijaˇci´c, Josep Balasch, Bohan Yang, Santosh Ghosh and Ingrid Verbauwhede. "Towards efficient and automated side-channel evaluations at design time". pp. 305-319. Journal of Cryptographic Engineering, 10(4). 2020. <https://www.esat.kuleuven.be/cosic/publications/article-3204.pdf>.
[REF-1232] Amit Kumar, Cody Scarborough, Ali Yilmaz and Michael Orshansky. "Efficient simulation of EM side-channel attack resilience". pp. 123-130. IEEE/ACM International Conference on Computer-Aided Design (ICCAD). 2017. <https://dl.acm.org/doi/pdf/10.5555/3199700.3199717>.
[REF-1233] Yuan Yao, Tuna Tufan, Tarun Kathuria, Baris Ege, Ulkuhan Guler and Patrick Schaumont. "Pre-silicon Architecture Correlation Analysis (PACA): Identifying and Mitigating the Source of Side-channel Leakage at Gate-level". IACR Cryptology ePrint Archive. 2021-04-21. <https://eprint.iacr.org/2021/530.pdf>.
[REF-1234] Elisabeth Oswald, Thomas Popp and Stefan Mangard. "Power Analysis Attacks - Revealing the Secrets of Smart Cards". 2007. <https://www.springer.com/gp/book/9780387308579>.
[REF-1235] David Oswald, Bastian Richter and Christof Paar. "Side-Channel Attacks on the Yubikey 2 One-Time Password Generator". 2013-06-14. <https://www.emsec.ruhr-uni-bochum.de/media/crypto/veroeffentlichungen/2014/02/04/paper_yubikey_sca.pdf>.
[REF-1239] François-Xavier Standaert. "How (not) to Use Welch's T-test in Side-Channel Security Evaluations". IACR Cryptology ePrint Archive. 2017-02-15. <https://eprint.iacr.org/2017/138.pdf>.
[REF-1240] Carolyn Whitnall and Elisabeth Oswald. "A Critical Analysis of ISO 17825 ('Testing methods for the mitigation of non-invasive attack classes against cryptographic modules')". IACR Cryptology ePrint Archive. 2019-09-10. <https://eprint.iacr.org/2019/1013.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-29Nicole FernTortuga Logic
+ Contributions
Contribution DateContributorOrganization
2021-10-11Anders Nordstrom, Alric AlthoffTortuga Logic
Provided detection methods, observed examples, and references
2021-10-13Nicole FernRiscure
Provided detection methods, observed examples, and references
+ Modifications
Modification DateModifierOrganization
2021-03-15CWE Content TeamMITRE
updated Functional_Areas, Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-1256: Improper Restriction of Software Interfaces to Hardware Features

Weakness ID: 1256
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.
+ Extended Description

It is frequently assumed that physical attacks such as fault injection and side-channel analysis require an attacker to have physical access to the target device. This assumption may be false if the device has improperly secured power management features, or similar features. For mobile devices, minimizing power consumption is critical, but these devices run a wide variety of applications with different performance requirements. Software-controllable mechanisms to dynamically scale device voltage and frequency and monitor power consumption are common features in today's chipsets, but they also enable attackers to mount fault injection and side-channel attacks without having physical access to the device.

Fault injection attacks involve strategic manipulation of bits in a device to achieve a desired effect such as skipping an authentication step, elevating privileges, or altering the output of a cryptographic operation. Manipulation of the device clock and voltage supply is a well-known technique to inject faults and is cheap to implement with physical device access. Poorly protected power management features allow these attacks to be performed from software. Other features, such as the ability to write repeatedly to DRAM at a rapid rate from unprivileged software, can result in bit flips in other memory locations (Rowhammer, [REF-1083]).

Side channel analysis requires gathering measurement traces of physical quantities such as power consumption. Modern processors often include power metering capabilities in the hardware itself (e.g., Intel RAPL) which if not adequately protected enable attackers to gather measurements necessary for performing side-channel attacks from software.

+ Relationships
Section HelpThis table 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.285Improper Authorization
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1206Power, Clock, and Reset Concerns
+ Modes Of Introduction
Section HelpThe 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 DesignAn architect may initiate introduction of this weakness via exacting requirements for software accessible power/clock management requirements
ImplementationAn implementer may introduce this weakness by assuming there are no consequences to unbounded power and clock management for secure components from untrusted ones.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

Memory IP (Undetermined Prevalence)

Power Management IP (Undetermined Prevalence)

Clock/Counter IP (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Integrity

Technical Impact: Modify Memory; Modify Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

This example considers the Rowhammer problem [REF-1083]. The Rowhammer issue was caused by a program in a tight loop writing repeatedly to a location to which the program was allowed to write but causing an adjacent memory location value to change.

(bad code)
Example Language: Other 
Continuously writing the same value to the same address causes the value of an adjacent location to change value.

Preventing the loop required to defeat the Rowhammer exploit is not always possible:

(good code)
Example Language: Other 
Redesign the RAM devices to reduce inter capacitive coupling making the Rowhammer exploit impossible.

While the redesign may be possible for new devices, a redesign is not possible in existing devices. There is also the possibility that reducing capacitance with a relayout would impact the density of the device resulting in a less capable, more costly device.

Example 2

Suppose a hardware design implements a set of software-accessible registers for scaling clock frequency and voltage but does not control access to these registers. Attackers may cause register and memory changes and race conditions by changing the clock or voltage of the device under their control.

Example 3

Consider the following SoC design. Security-critical settings for scaling clock frequency and voltage are available in a range of registers bounded by [PRIV_END_ADDR : PRIV_START_ADDR] in the tmcu.csr module in the HW Root of Trust. These values are writable based on the lock_bit register in the same module. The lock_bit is only writable by privileged software running on the tmcu.

Hardware Root of Trust

We assume that untrusted software running on any of the Core{0-N} processors has access to the input and output ports of the hrot_iface. If untrusted software can clear the lock_bit or write the clock frequency and voltage registers due to inadequate protection, a fault injection attack could be performed.

+ Observed Examples
ReferenceDescription
Plundervolt: Improper conditions check in voltage settings for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege and/or information disclosure via local access [REF-1081].
PLATYPUS Attack: Insufficient access control in the Linux kernel driver for some Intel processors allows information disclosure.
Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
AMD extension to a Linux service does not require privileged access to the RAPL interface, allowing side-channel attacks.
NaCl in 2015 allowed the CLFLUSH instruction, making Rowhammer attacks possible.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Perform a security evaluation of system-level architecture and design with software-aided physical attacks in scope.

Automated Dynamic Analysis

Use custom software to change registers that control clock settings or power settings to try to bypass security locks, or repeatedly write DRAM to try to change adjacent locations. This can be effective in extracting or changing data. The drawback is that it cannot be run before manufacturing, and it may require specialized software.

Effectiveness: Moderate

+ Functional Areas
  • Power
  • Clock
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ References
[REF-1081] Kit Murdock, David Oswald, Flavio D Garcia, Jo Van Bulck, Frank Piessens and Daniel Gruss. "Plundervolt". <https://plundervolt.com/>.
[REF-1082] Adrian Tang, Simha Sethumadhavan and Salvatore Stolfo. "CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management". <https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tang.pdf>.
[REF-1083] Yoongu Kim, Ross Daly, Jeremie Kim, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai and Onur Mutlu. "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors". <https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf>.
[REF-1225] Project Zero. "Exploiting the DRAM rowhammer bug to gain kernel privileges". 2015-03-09. <https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html>.
[REF-1217] Ross Anderson. "Security Engineering". 2001. <https://www.cl.cam.ac.uk/~rja14/musicfiles/manuscripts/SEv1.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-08Nicole FernTortuga Logic
+ Contributions
Contribution DateContributorOrganization
2021-07-16Tortuga Logic
Provided Demonstrative Example for Hardware Root of Trust
2021-10-11Anders Nordstrom, Alric AlthoffTortuga Logic
Provided detection method
2021-10-15Nicole FernRiscure
updated description and extended description, detection method, and observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Functional_Areas, Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples

CWE-1244: Internal Asset Exposed to Unsafe Debug Access Level or State

Weakness ID: 1244
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product uses physical debug or test interfaces with support for multiple access levels, but it assigns the wrong debug access level to an internal asset, providing unintended access to the asset from untrusted debug agents.
+ Extended Description

Debug authorization can have multiple levels of access, defined such that different system internal assets are accessible based on the current authorized debug level. Other than debugger authentication (e.g., using passwords or challenges), the authorization can also be based on the system state or boot stage. For example, full system debug access might only be allowed early in boot after a system reset to ensure that previous session data is not accessible to the authenticated debugger.

If this protection mechanism does not ensure that internal assets have the correct debug access level during each boot stage or change in system state, an attacker could obtain sensitive information from the internal asset using a debugger.

+ Relationships
Section HelpThis table 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.863Incorrect Authorization
Section HelpThis table 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 "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
Section HelpThe 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
Section HelpThis listing shows 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
Section HelpThis table 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

Technical Impact: Read Memory

Integrity

Technical Impact: Modify Memory

Authorization
Access Control

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The JTAG interface is used to perform debugging and provide CPU core access for developers. JTAG-access protection is implemented as part of the JTAG_SHIELD bit in the hw_digctl_ctrl register. This register has no default value at power up and is set only after the system boots from ROM and control is transferred to the user software.

(bad code)
Example Language: Other 
1 bit 0x0 = JTAG debugger is enabled (default)
JTAG_SHIELD 0x1 = JTAG debugger is disabled

This means that since the end user has access to JTAG at system reset and during ROM code execution before control is transferred to user software, a JTAG user can modify the boot flow and subsequently disclose all CPU information, including data-encryption keys.

(informative)
 
The default value of this register bit should be set to 1 to prevent the JTAG from being enabled at system reset.
+ Observed Examples
ReferenceDescription
After ROM code execution, JTAG access is disabled. But before the ROM code is executed, JTAG access is possible, allowing a user full system access. This allows a user to modify the boot flow and successfully bypass the secure-boot process.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

For security-sensitive assets accessible over debug/test interfaces, only allow trusted agents.

Effectiveness: High

Phase: Architecture and Design

Apply blinding [REF-1219] or masking techniques in strategic areas.

Effectiveness: Limited

Phase: Implementation

Add shielding or tamper-resistant protections to the device, which increases the difficulty and cost for accessing debug/test interfaces.

Effectiveness: Limited

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Check 2 devices for their passcode to authenticate access to JTAG/debugging ports. If the passcodes are missing or the same, update the design to fix and retest. Check communications over JTAG/debugging ports for encryption. If the communications are not encrypted, fix the design and retest.

Effectiveness: Moderate

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Relationship

CWE-1191 and CWE-1244 both involve physical debug access, but the weaknesses are different. CWE-1191 is effectively about missing authorization for a debug interface, i.e. JTAG. CWE-1244 is about providing internal assets with the wrong debug access level, exposing the asset to untrusted debug agents.
+ References
[REF-1056] F-Secure Labs. "Multiple Vulnerabilities in Barco Clickshare: JTAG access is not permanently disabled". <https://labs.f-secure.com/advisories/multiple-vulnerabilities-in-barco-clickshare/>.
[REF-1057] Kurt Rosenfeld and Ramesh Karri. "Attacks and Defenses for JTAG". <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5406671>.
[REF-1219] Monodeep Kar, Arvind Singh, Santosh Ghosh, Sanu Mathew, Anand Rajan, Vivek De, Raheem Beyah and Saibal Mukhopadhyay. "Blindsight: Blinding EM Side-Channel Leakage using Built-In Fully Integrated Inductive Voltage Regulator". 2018-02. <https://www.researchgate.net/publication/323411019_Blindsight_Blinding_EM_Side-Channel_Leakage_using_Built-In_Fully_Integrated_Inductive_Voltage_Regulator>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-22Hareesh KhattriIntel Corporation
clarified differences between CWE-1191 and CWE-1244, and suggested rephrasing of descriptions and names.
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Name, Observed_Examples, Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Improper Authorization on Physical Debug and Test Interfaces

CWE-1191: On-Chip Debug and Test Interface With Improper Access Control

Weakness ID: 1191
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.
+ Extended Description

A device's internal information may be accessed through a scan chain of interconnected internal registers, usually through a JTAG interface. The JTAG interface provides access to these registers in a serial fashion in the form of a scan chain for the purposes of debugging programs running on a device. Since almost all information contained within a device may be accessed over this interface, device manufacturers typically insert some form of authentication and authorization to prevent unintended use of this sensitive information. This mechanism is implemented in addition to on-chip protections that are already present.

If authorization, authentication, or some other form of access control is not implemented or not implemented correctly, a user may be able to bypass on-chip protection mechanisms through the debug interface.

+ Relationships
Section HelpThis table 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
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
PeerOfClassClass - 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.1263Improper Physical Access Control
Section HelpThis table 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 "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
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1299Missing Protection Mechanism for Alternate Hardware Interface
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Read Application Data

High
Confidentiality

Technical Impact: Read Memory

High
Authorization

Technical Impact: Execute Unauthorized Code or Commands

High
Integrity

Technical Impact: Modify Memory

High
Integrity

Technical Impact: Modify Application Data

High
Access Control

Technical Impact: Bypass Protection Mechanism

High
+ Demonstrative Examples

Example 1

A home, WiFi-router device implements a login prompt which prevents an unauthorized user from issuing any commands on the device until appropriate credentials are provided. The credentials are protected on the device and are checked for strength against attack.

(bad code)
Example Language: Other 

If the JTAG interface on this device is not hidden by the manufacturer, the interface may be identified using tools such as JTAGulator. If it is hidden but not disabled, it can be exposed by physically wiring to the board.

By issuing a halt command before the OS starts, the unauthorized user pauses the watchdog timer and prevents the router from restarting (once the watchdog timer would have expired). Having paused the router, an unauthorized user is able to execute code and inspect and modify data in the device, even extracting all of the router's firmware. This allows the user to examine the router and potentially exploit it.

JTAG is useful to chip and device manufacturers during design, testing, and production and is included in nearly every product. Without proper authentication and authorization, the interface may allow tampering with a product.

(good code)
Example Language: Other 
In order to prevent exposing the debugging interface, manufacturers might try to obfuscate the JTAG interface or blow device internal fuses to disable the JTAG interface. Adding authentication and authorization to this interface makes use by unauthorized individuals much more difficult.
+ Observed Examples
ReferenceDescription
chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

If feasible, the manufacturer should disable the JTAG interface or implement authentication and authorization for the JTAG interface. If authentication logic is added, it should be resistant to timing attacks. Security-sensitive data stored in registers, such as keys, etc. should be cleared when entering debug mode.

Effectiveness: High

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Dynamic Analysis with Manual Results Interpretation

Authentication and authorization of debug and test interfaces should be part of the architecture and design review process. Withholding of private register documentation from the debug and test interface public specification ("Security by obscurity") should not be considered as sufficient security.

Dynamic Analysis with Manual Results Interpretation

Dynamic tests should be done in the pre-silicon and post-silicon stages to verify that the debug and test interfaces are not open by default.

Fuzzing

Tests that fuzz Debug and Test Interfaces should ensure that no access without appropriate authentication and authorization is possible.

Effectiveness: Moderate

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Relationship

CWE-1191 and CWE-1244 both involve physical debug access, but the weaknesses are different. CWE-1191 is effectively about missing authorization for a debug interface, i.e. JTAG. CWE-1244 is about providing internal assets with the wrong debug access level, exposing the asset to untrusted debug agents.
+ References
[REF-1037] Kurt Rosenfeld and Ramesh Karri. "Attacks and Defenses for JTAG". 2010-02. <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5406671>.
[REF-1043] Gopal Vishwakarma and Wonjun Lee. "Exploiting JTAG and Its Mitigation in IOT: A Survey". 2018-12-03. <https://www.mdpi.com/1999-5903/10/12/121/pdf>.
[REF-1084] Gopal Vishwakarma and Wonjun Lee. "JTAG Explained (finally!): Why “IoT”, Software Security Engineers, and Manufacturers Should Care". <https://www.mdpi.com/1999-5903/10/12/121/pdf >.
[REF-1085] Bob Molyneaux, Mark McDermott and Anil Sabbavarapu. "Design for Testability & Design for Debug". <http://users.ece.utexas.edu/~mcdermot/vlsi-2/Lecture_17.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-18Parbati K. MannaIntel Corporation
provided detection methods
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
reviewed content changes
2021-10-22Hareesh KhattriIntel Corporation
clarified differences between CWE-1191 and CWE-1244
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, References, Relationships
2020-08-20CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-26Exposed Chip Debug Interface With Insufficient Access Control
2020-08-20Exposed Chip Debug and or Test Interface With Insufficient Access Control

CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection

Weakness ID: 1233
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.
+ Extended Description

Integrated circuits and hardware intellectual properties (IPs) might provide device configuration controls that need to be programmed after device power reset by a trusted firmware or software module, commonly set by BIOS/bootloader. After reset, there can be an expectation that the controls cannot be used to perform any further modification. This behavior is commonly implemented using a trusted lock bit, which can be set to disable writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration).

However, if the lock bit does not effectively write-protect all system registers or controls that could modify the protected system configuration, then an adversary may be able to use software to access the registers/controls and modify the protected hardware configuration.

+ Relationships
Section HelpThis table 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.667Improper Locking
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction
Section HelpThe 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 DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Modify Memory

System Configuration protected by the lock bit can be modified even when the lock is set.
+ Demonstrative Examples

Example 1

Consider the example design below for a digital thermal sensor that detects overheating of the silicon and triggers system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by the firmware.

(bad code)
Example Language: Other 
Register Field description
CRITICAL_TEMP_LIMIT [31:8] Reserved field; Read only; Default 0

[7:0] Critical temp 0-255 Centigrade; Read-write-lock; Default 125
TEMP_SENSOR_CALIB [31:0] Thermal sensor calibration data. A slope value used to map sensor reading to a degree Centigrade. Read-write; Default 25
TEMP_SENSOR_LOCK [31:1] Reserved field; Read only; Default 0

[0] Lock bit, locks CRITICAL_TEMP_LIMIT register; Write-1-once; Default 0
TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0

[1] Enable hardware shutdown on a critical temperature detection; Read-write; Default 0
CURRENT_TEMP [31:8] Reserved field; Read only; Default 0

[7:0] Current Temp 0-255 Centigrade; Read-only; Default 0

In this example note that only the CRITICAL_TEMP_LIMIT register is protected by the TEMP_SENSOR_LOCK bit, while the security design intent is to protect any modification of the critical temperature detection and response.

The response of the system, if the system heats to a critical temperature, is controlled by TEMP_HW_SHUTDOWN bit [1], which is not lockable. Also, the TEMP_SENSOR_CALIB register is not protected by the lock bit.

By modifying the temperature sensor calibration, the conversion of the sensor data to a degree centigrade can be changed, such that the current temperature will never be detected to exceed critical temperature value programmed by the protected lock.

Similarly, by modifying the TEMP_HW_SHUTDOWN.Enable bit, the system response detection of the current temperature exceeding critical temperature can be disabled.

(good code)
 

Change TEMP_HW_SHUTDOWN and TEMP_SENSOR_CALIB controls to be locked by TEMP_SENSOR_LOCK.

TEMP_SENSOR_CALIB [31:0] Thermal sensor calibration data. A slope value used to map sensor reading to a degree Centigrade. Read-write-Lock; Default 25; Locked by TEMP_SENSOR_LOCK bit[0]
TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0

[1] Enable hardware shutdown on critical temperature detection; Read-write-Lock; Default 0; Locked by TEMP_SENSOR_LOCK bit[0]
+ Observed Examples
ReferenceDescription
Certain servers leave a write protection lock bit unset after boot, potentially allowing modification of parts of flash memory.
Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security lock bit protections must be reviewed for design inconsistency and common weaknesses.
  • Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Set the lock bit. Attempt to modify the information protected by the lock bit. If the information is changed, implement a design fix. Retest. Also, attempt to indirectly clear the lock bit or bypass it.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ References
[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
reviewed content changes
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes

CWE-1272: Sensitive Information Uncleared Before Debug/Power State Transition

Weakness ID: 1272
Abstraction: Base
Structure: Simple
Status: Stable
Presentation Filter:
+ Description
The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.
+ Extended Description

A device or system frequently employs many power and sleep states during its normal operation (e.g., normal power, additional power, low power, hibernate, deep sleep, etc.). A device also may be operating within a debug condition. State transitions can happen from one power or debug state to another. If there is information available in the previous state which should not be available in the next state and is not properly removed before the transition into the next state, sensitive information may leak from the system.

+ Relationships
Section HelpThis table 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
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.226Sensitive Information in Resource Not Removed Before Reuse
CanPrecedeClassClass - 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
Section HelpThis table 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 "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
Section HelpThe 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
+ Applicable Platforms
Section HelpThis listing shows 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

VHDL (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

Class: Compiled (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Read Memory; Read Application Data

Sensitive information may be used to unlock additional capabilities of the device and take advantage of hidden functionalities which could be used to compromise device security.
High
+ Demonstrative Examples

Example 1

This example shows how an attacker can take advantage of an incorrect state transition.

Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

(bad code)
 

During the transition from A to B, the device does not scrub the memory.

After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

(good code)
 
For transition from state A to state B, remove information which should not be available once the transition is complete.
+ Observed Examples
ReferenceDescription
Product software does not set a flag as per TPM specifications, thereby preventing a failed authorization attempt from being recorded after a loss of power.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

During state transitions, information not needed in the next state should be removed before the transition to the next state.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the device needs to be fixed. Note that this test can likely be automated.

Effectiveness: High

+ Functional Areas
  • Power
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ References
[REF-1220] Zhenyu Ning and Fengwei Zhang. "Understanding the Security of ARM Debugging Features". 2019 IEEE Symposium on Security and Privacy (SP). 2019-05-22. <https://www.computer.org/csdl/proceedings-article/sp/2019/666000b156/19skgcwSgsE>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-31Parbati Kumar Manna, Hareesh Khattri, Arun KanuparthiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships
2021-03-15CWE Content TeamMITRE
updated Functional_Areas
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Debug/Power State Transitions Leak Information

CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation

Weakness ID: 1240
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.
+ Extended Description

Cryptographic protocols and systems depend on cryptographic primitives (and associated algorithms) as their basic building blocks. Some common examples of primitives are digital signatures, one-way hash functions, ciphers, and public key cryptography; however, the notion of "primitive" can vary depending on point of view. See "Terminology Notes" for further explanation of some concepts.

Cryptographic primitives are defined to accomplish one very specific task in a precisely defined and mathematically reliable fashion. For example, suppose that for a specific cryptographic primitive (such as an encryption routine), the consensus is that the primitive can only be broken after trying out N different inputs (where the larger the value of N, the stronger the cryptography). For an encryption scheme like AES-256, one would expect N to be so large as to be infeasible to execute in a reasonable amount of time.

If a vulnerability is ever found that shows that one can break a cryptographic primitive in significantly less than the expected number of attempts, then that primitive is considered weakened (or sometimes in extreme cases, colloquially it is "broken"). As a result, anything using this cryptographic primitive would now be considered insecure or risky. Thus, even breaking or weakening a seemingly small cryptographic primitive has the potential to render the whole system vulnerable, due to its reliance on the primitive. A historical example can be found in TLS when using DES. One would colloquially call DES the cryptographic primitive for transport encryption in this version of TLS. In the past, DES was considered strong, because no weaknesses were found in it; importantly, DES has a key length of 56 bits. Trying N=2^56 keys was considered impractical for most actors. Unfortunately, attacking a system with 56-bit keys is now practical via brute force, which makes defeating DES encryption practical. It is now practical for an adversary to read any information sent under this version of TLS and use this information to attack the system. As a result, it can be claimed that this use of TLS is weak, and that any system depending on TLS with DES could potentially render the entire system vulnerable to attack.

Cryptographic primitives and associated algorithms are only considered safe after extensive research and review from experienced cryptographers from academia, industry, and government entities looking for any possible flaws. Furthermore, cryptographic primitives and associated algorithms are frequently reevaluated for safety when new mathematical and attack techniques are discovered. As a result and over time, even well-known cryptographic primitives can lose their compliance status with the discovery of novel attacks that might either defeat the algorithm or reduce its robustness significantly.

If ad-hoc cryptographic primitives are implemented, it is almost certain that the implementation will be vulnerable to attacks that are well understood by cryptographers, resulting in the exposure of sensitive information and other consequences.

This weakness is even more difficult to manage for hardware-implemented deployment of cryptographic algorithms. First, because hardware is not patchable as easily as software, any flaw discovered after release and production typically cannot be fixed without a recall of the product. Secondly, the hardware product is often expected to work for years, during which time computation power available to the attacker only increases. Therefore, for hardware implementations of cryptographic primitives, it is absolutely essential that only strong, proven cryptographic primitives are used.

+ Relationships
Section HelpThis table 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.327Use of a Broken or Risky Cryptographic Algorithm
Section HelpThis table 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
+ Modes Of Introduction
Section HelpThe 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 DesignThis weakness is primarily introduced during the architecture and design phase as risky primitives are included.
ImplementationEven in cases where the Architectural phase properly specifies a cryptographically secure design, the design may be changed during implementation due to unforeseen constraints.
+ Applicable Platforms
Section HelpThis listing shows 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
Section HelpThis table 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

Technical Impact: Read Application Data

Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.
High
+ Demonstrative Examples

Example 1

Re-using random values may compromise security.

(bad code)
 
Suppose an Encryption algorithm needs a random value for a key. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a linear-feedback shift register (LFSR) to generate the value.

While an LFSR may provide pseudo-random number generation service, the entropy (measure of randomness) of the resulting output may be less than that of an accepted DRNG (like that used in dev/urandom). Thus, using an LFSR weakens the strength of the cryptographic system, because it may be possible for an attacker to guess the LFSR output and subsequently the encryption key.

(good code)
 
If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.
+ Observed Examples
ReferenceDescription
software uses MD5, which is less safe than the default SHA-256 used by related products
Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
identity card uses MD5 hash of a salt and password
personal key is transmitted over the network using a substitution cipher
product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.
SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher's requirements for unique nonces.
LDAP interface allows use of weak ciphers
SCADA product allows "use of outdated cipher suites"
Chip implementing Bluetooth uses a low-entropy PRNG instead of a hardware RNG, allowing spoofing.
security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
Dual_EC_DRBG implementation in RSA toolkit does not correctly handle certain byte requests, simplifying plaintext recovery
Recommendation for Dual_EC_DRBG algorithm contains point Q constants that could simplify decryption
+ Potential Mitigations

Phase: Requirements

Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].

Effectiveness: High

Phase: Architecture and Design

Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].

Effectiveness: High

Phase: Architecture and Design

Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.

Effectiveness: Discouraged Common Practice

Phase: Architecture and Design

Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.

Effectiveness: Discouraged Common Practice

Phase: Architecture and Design

Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation ("cryptographic agility"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.

Effectiveness: Defense in Depth

Phase: Architecture and Design

Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267].

Effectiveness: Discouraged Common Practice

Phases: Architecture and Design; Implementation

Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.

Effectiveness: Discouraged Common Practice

Phases: Architecture and Design; Implementation

Do not use a checksum as a substitute for a cryptographically generated hash.

Effectiveness: Discouraged Common Practice

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation.

Effectiveness: High

Phases: Architecture and Design; Implementation

When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.

Effectiveness: Moderate

Phases: Architecture and Design; Implementation

Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.

Effectiveness: Moderate

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Architecture or Design Review

Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.

Effectiveness: High

Manual Analysis

Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.

Effectiveness: Moderate

Dynamic Analysis with Manual Results Interpretation

For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236].

Effectiveness: Moderate

Dynamic Analysis with Manual Results Interpretation

It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).

Effectiveness: Moderate

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Maintenance

Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.

Terminology

Terminology for cryptography varies widely, from informal and colloquial to mathematically-defined, with different precision and formalism depending on whether the stakeholder is a developer, cryptologist, etc. Yet there is a need for CWE to be self-consistent while remaining understandable and acceptable to multiple audiences.

As of CWE 4.6, CWE terminology around "primitives" and "algorithms" is emerging as shown by the following example, subject to future consultation and agreement within the CWE and cryptography communities. Suppose one wishes to send encrypted data using a CLI tool such as OpenSSL. One might choose to use AES with a 256-bit key and require tamper protection (GCM mode, for instance). For compatibility's sake, one might also choose the ciphertext to be formatted to the PKCS#5 standard. In this case, the "cryptographic system" would be AES-256-GCM with PKCS#5 formatting. The "cryptographic function" would be AES-256 in the GCM mode of operation, and the "algorithm" would be AES. Colloquially, one would say that AES (and sometimes AES-256) is the "cryptographic primitive," because it is the algorithm that realizes the concept of symmetric encryption (without modes of operation or other protocol related modifications). In practice, developers and architects typically refer to base cryptographic algorithms (AES, SHA, etc.) as cryptographic primitives.

+ References
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>.
[REF-1227] Wikipedia. "Cryptographic primitive". <https://en.wikipedia.org/wiki/Cryptographic_primitive>.
[REF-1226] Information Technology Laboratory, National Institute of Standards and Technology. "FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/publications/detail/fips/140/2/final>.
[REF-1192] Information Technology Laboratory, National Institute of Standards and Technology. "FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2019-03-22. <https://csrc.nist.gov/publications/detail/fips/140/3/final>.
[REF-1236] NIST. "CAVP Testing: Individual Component Testing". Test Vectors. <https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/component-testing>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-18Parbati K. MannaIntel Corporation
provided detection methods and observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns, Research_Gaps
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes, Research_Gaps
More information is available — Please select a different filter.
Page Last Updated: October 26, 2021