CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.5)  
ID

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

Weakness ID: 1189
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product 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 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
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
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
+ 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.

+ 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.

+ Detection Methods

Automated Static Analysis - Binary or Bytecode

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

Effectiveness: High

+ 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>.
+ 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
+ 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)
More information is available — Please select a different filter.
Page Last Updated: July 20, 2021