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.
View on MITREA 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. Sometimes, designers choose not to expose the debug pins on the motherboard. Instead, they choose to hide these pins in the intermediate layers of the board. This is primarily done to work around the lack of debug authorization inside the chip. In such a scenario (without debug authorization), when the debug interface is exposed, chip internals are accessible to an attacker.
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.
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 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.
Tests that fuzz Debug and Test Interfaces should ensure that no access without appropriate authentication and authorization is possible.
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.
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.
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.
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.
The following example code is a snippet from the JTAG wrapper module in the RISC-V debug module of the HACK@DAC'21 Openpiton SoC [REF-1355]. To make sure that the JTAG is accessed securely, the developers have included a primary authentication mechanism based on a password.
The developers employed a Finite State Machine (FSM) to implement this authentication. When a user intends to read from or write to the JTAG module, they must input a password.
The following example code is a snippet from the JTAG wrapper module in the RISC-V debug module of the HACK@DAC'21 Openpiton SoC [REF-1355]. To make sure that the JTAG is accessed securely, the developers have included a primary authentication mechanism based on a password.
The developers employed a Finite State Machine (FSM) to implement this authentication. When a user intends to read from or write to the JTAG module, they must input a password.
The example code below is taken from the JTAG access control mechanism of the HACK@DAC'21 buggy OpenPiton SoC [REF-1364]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.
The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks on the access control mechanism of JTAG, where the attacker only needs to determine 32 bits of the secret message instead of 512 bits.
The example code below is taken from the JTAG access control mechanism of the HACK@DAC'21 buggy OpenPiton SoC [REF-1364]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.
The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks on the access control mechanism of JTAG, where the attacker only needs to determine 32 bits of the secret message instead of 512 bits.
chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
View DetailsNo relationship information available for this CWE.
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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. 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. Sometimes, designers choose not to expose the debug pins on the motherboard. Instead, they choose to hide these pins in the intermediate layers of the board. This is primarily done to work around the lack of debug authorization inside the chip. In such a scenario (without debug authorization), when the debug interface is exposed, chip internals are accessible to an attacker.
If exploited, CWE-1191 (On-Chip Debug and Test Interface With Improper Access Control) it can compromise Confidentiality, Authorization, Integrity and Access Control, leading to outcomes such as Read Application Data, Read Memory, Execute Unauthorized Code or Commands, Modify Memory, Modify Application Data and Bypass Protection Mechanism.
Recommended mitigations for CWE-1191 include: 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.
CWE-1191 can be detected using Dynamic Analysis with Manual Results Interpretation and Fuzzing. Combining automated tooling with manual review typically yields the best coverage.
CWE-1191 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-1191, including CVE-2019-18827. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-1191 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.