Improper Access to Sensitive Information Using Debug and Test Interfaces

The product's physical debug and test interface protection does not block untrusted agents, resulting in unauthorized access to and potentially control of sensitive assets.


If the product implements access-control protection on the debug and test interface, a debugger is typically required to enter either a valid response to a challenge provided by the authorization logic or, alternatively, enter the right password in order to exercise the debug and test interface. However, if this protection mechanism does not exclude all untrusted, debug agents, an attacker could access/control security-sensitive registers.


The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

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.

1 bit0x0 = JTAG debugger is enabled (default)JTAG_SHIELD0x1 = JTAG debugger is disabled

This means that as 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.

The default value of this register bit should be set to 1 to prevent the JTAG from being enabled at system reset.

See Also

Debug and Test Problems

Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses without Software Fault Patterns

CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.

Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.