CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

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

CWE-1276: Hardware Block Incorrectly Connected to Larger System

Weakness ID: 1276
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Signals between a hardware IP and the larger system design are incorrectly connected.
+ Extended Description

Individual hardware IP must communicate with the larger system in order for the product to function correctly and as intended. If implemented incorrectly, these various inputs and output interactions may cause security issues that will not necessarily manifest as functional bugs. For example, if the IP should only be reset by a system-wide hard reset, but instead the reset input is connected to a software-triggered debug mode reset (which is also asserted during a hard reset), integrity of data inside the IP can be violated.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
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
+ 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.1197Integration Issues
+ Modes Of Introduction

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

PhaseNote
ImplementationThis weakness is introduced when integrating IP into a larger design.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Many SoCs use hardware to partition system resources between secure/trusted and non-secure/un-trusted entities. An example of this is Arm TrustZone, in which the processor and all security-aware IP must isolate resources based on the status of a privilege bit. This privilege bit is part of the input interface in all TrustZone-aware IP. If this privilege bit is accidentally grounded or left unconnected when the IP is instantiated, privilege escalation of all input data can occur.

(bad code)
Example Language: Verilog 

// IP definition

module tz_peripheral(clk, reset, data_in, data_in_security_level, ...);

input clk, reset;

input [31:0] data_in;

input data_in_security_level;

...

endmodule

// Instantiation of IP in a larger system

module soc(...)

...

tz_peripheral u_tz_peripheral(

.clk(clk),

.rst(rst),

.data_in(rdata),

//Copy-and-paste error or typo grounds data_in_security_level (in this example 0=secure, 1=non-secure) effectively promoting all data to “secure”)

.data_in_security_level(1'b0),

);

...

endmodule

In the Verilog code below, the security level input to the TrustZone aware peripheral is correctly driven by an appropriate signal instead of being grounded.

(good code)
Example Language: Verilog 

// Instantiation of IP in a larger system

module soc(...)

...

tz_peripheral u_tz_peripheral(

.clk(clk),

.rst(rst),

.data_in(rdata),

// This port is no longer grounded, but instead drive by the appropriate signal

.data_in_security_level(rdata_security_level),

);

...

endmodule

+ Potential Mitigations

Phase: Testing

System-level verification is essential to ensure that components are correctly connected and that design security requirements are not violated due to interactions between various IP blocks.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-22Nicole FernTortuga Logic
More information is available — Please select a different filter.
Page Last Updated: June 25, 2020