CWE-1191 covers chips that do not implement, or do not correctly perform, access control on internal registers and test modes reachable through the physical debug or test interface. If you design silicon, build boards or ship devices that include a debug port, this one applies to you.
How it happens
A device's internal state can be reached through a scan chain of interconnected internal registers, usually over a JTAG interface. JTAG reads these registers serially so that engineers can debug programs running on the device. Because almost everything inside the device can be reached this way, manufacturers normally add authentication and authorization on top of the on-chip protections that already exist.
When that access control is missing or flawed, a user can bypass the on-chip protection mechanisms through the debug interface.
MITRE describes a common workaround that does not fix the problem. Some designers hide the debug pins in the intermediate layers of the board instead of exposing them. This is mostly done to avoid the lack of debug authorization inside the chip. If the interface is ever exposed, the chip internals are open to an attacker.
The observed example is CVE-2019-18827, a chain where the JTAG interface was not disabled during ROM code execution. That introduced a race condition that allowed extraction of encryption keys.
What an attacker gains
The record lists consequences across several areas, all rated high:
- Confidentiality: reading application data and reading memory.
- Authorization: executing unauthorized code or commands.
- Integrity: modifying memory and modifying application data.
In short, an open debug port can mean full read and write access to the device.
How to find it
MITRE lists three approaches.
- Review authentication and authorization of debug and test interfaces as part of architecture and design review. MITRE notes that withholding private register documentation from the public specification is security by obscurity and should not be relied on.
- Run dynamic tests in the pre-silicon and post-silicon stages to verify the interfaces are not open by default.
- Fuzz the debug and test interfaces to confirm that no access without proper authentication and authorization is possible.
How to fix it
MITRE's mitigation, rated high effectiveness, uses separation of privilege.
- If feasible, disable the JTAG interface, or implement authentication and authorization for it.
- If you add authentication logic, make it resistant to timing attacks.
- Clear security sensitive data stored in registers, such as keys, when the device enters debug mode.
Hiding pins is not on that list, and for good reason. Treat the physical port as reachable and protect it in the chip.
The CVE above adds a lesson about boot order. A debug interface that stays enabled while early code runs gives an attacker a window, so confirm the port is closed before sensitive operations begin.
Quick check
Is hiding the debug pins inside the board a fix?
No. MITRE describes it as a workaround for lacking debug authorization. If the interface is exposed, the chip internals are accessible.
What should happen to keys when the device enters debug mode?
Security sensitive data in registers, such as keys, should be cleared when entering debug mode.
What test shows a debug port is safe by default?
Pre-silicon and post-silicon dynamic tests that verify the interfaces are not open by default, plus fuzzing that confirms no unauthenticated access is possible.
