2155
Appropriate Post-Si tests should be carried out at various authorization levels to ensure
that debug components are properly chained and accessible only to users with appropriate
credentials.
Effectiveness = High
Dynamic Analysis with Manual Results Interpretation
Appropriate Post-Si tests should be carried out at various authorization levels to ensure
that debug components are properly chained and accessible only to users with appropriate
credentials.
Effectiveness = High
Potential Mitigations
Phase: Implementation
Ensure that debug components are properly chained and their granularity is maintained at
different authentication levels.
Demonstrative Examples
Example 1:
The following example shows how an attacker can take advantage of incorrect chaining or missing
granularity of debug components.
In a System-on-Chip (SoC), the user might be able to access the SoC-level TAP with a certain level
of authorization. However, this access should not also grant access to all of the internal TAPs (e.g.,
Core). Separately, if any of the internal TAPs is also stitched to the TAP chain when it should not
be because of a logic error, then an attacker can access the internal TAPs as well and execute
commands there.
As a related example, suppose there is a hierarchy of TAPs (TAP_A is connected to TAP_B and
TAP_C, then TAP_B is connected to TAP_D and TAP_E, then TAP_C is connected to TAP_F and
TAP_G, etc.). Architecture mandates that the user have one set of credentials for just accessing
TAP_A, another set of credentials for accessing TAP_B and TAP_C, etc. However, if, during
implementation, the designer mistakenly implements a daisy-chained TAP where all the TAPs are
connected in a single TAP chain without the hierarchical structure, the correct granularity of debug
components is not implemented and the attacker can gain unauthorized access.
Observed Examples
Reference Description
CVE-2017-18347 Incorrect access control in RDP Level 1 on STMicroelectronics STM32F0
series devices allows physically present attackers to extract the device's
protected firmware via a special sequence of Serial Wire Debug (SWD)
commands because there is a race condition between full initialization of the
SWD interface and the setup of flash protection.
https://www.cve.org/CVERecord?id=CVE-2017-18347
CVE-2020-1791 There is an improper authorization vulnerability in several smartphones. The
system has a logic-judging error, and, under certain scenarios, a successful
exploit could allow the attacker to switch to third desktop after a series of
operations in ADB mode. (Vulnerability ID: HWPSIRT-2019-10114).
https://www.cve.org/CVERecord?id=CVE-2020-1791
MemberOf Relationships
This MemberOf relationships table shows additional CWE Catgeories 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.
Nature Type ID Name Page
MemberOf 1207 Debug and Test Problems 1194 2474
CWE Version 4.14
CWE-1297: Unprotected Confidential Information on Device is Accessible by OSAT Vendors
CWE-1297: Unprotected Confidential Information
on Device is Accessible by OSAT Vendors 2156
Nature Type ID Name Page
MemberOf 1396 Comprehensive Categorization: Access Control 1400 2519
Notes
Maintenance
This entry is still under development and will continue to see updates and content improvements.
Related Attack Patterns
CAPEC-ID Attack Pattern Name
121 Exploit Non-Production Interfaces
702 Exploiting Incorrect Chaining or Granularity of Hardware Debug Components
CWE-1297: Unprotected Confidential Information on Device is Accessible by
OSAT Vendors
Weakness ID : 1297
Structure : Simple
Abstraction : Base
Description
The product does not adequately protect confidential information on the device from being
accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.
Extended Description
In contrast to complete vertical integration of architecting, designing, manufacturing, assembling,
and testing chips all within a single organization, an organization can choose to simply architect
and design a chip before outsourcing the rest of the process to OSAT entities (e.g., external
foundries and test houses). In the latter example, the device enters an OSAT facility in a much
more vulnerable pre-production stage where many debug and test modes are accessible.
Therefore, the chipmaker must place a certain level of trust with the OSAT. To counter this, the
chipmaker often requires the OSAT partner to enter into restrictive non-disclosure agreements
(NDAs). Nonetheless, OSAT vendors likely have many customers, which increases the risk of
accidental sharing of information. There may also be a security vulnerability in the information
technology (IT) system of the OSAT facility. Alternatively, a malicious insider at the OSAT facility
may carry out an insider attack. Considering these factors, it behooves the chipmaker to minimize
any confidential information in the device that may be accessible to the OSAT vendor.
Logic errors during design or synthesis could misconfigure the interconnection of the debug
components, which could provide improper authorization to sensitive information.
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, MemberOr 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 may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 285 Improper Authorization 684
Applicable Platforms
Language : Verilog (Prevalence = Undetermined)
Language : VHDL (Prevalence = Undetermined)
CWE Version 4.14
CWE-1297: Unprotected Confidential Information on Device is Accessible by OSAT Vendors
CWE-1297: Unprotected Confidential Information
on Device is Accessible by OSAT Vendors