CWE-1296 is a chip design weakness: the product's debug components are chained incorrectly or at the wrong granularity. Debug hardware is meant for engineers. When its wiring is off, it becomes a door for anyone with physical access to the part.
How it happens
Chips carry a lot of hardware that exists only so people can troubleshoot them. MITRE lists several kinds. Test Access Ports (TAPs) allow boundary scan commands to be executed. Scan cells let the chip act as a stimulus and response mechanism for checking internal components. Chipmakers may also place tracing hubs inside the chip and link them into hierarchical or interconnected structures to observe internal behavior.
Those links are where the trouble starts. MITRE notes that logic errors during design or synthesis could misconfigure the interconnection of debug components, which could allow unintended access permissions. In practice that can mean two things.
- Chaining: a component that should sit behind an authentication level is reachable from a lower one because of how the chain is wired.
- Granularity: access is granted to a whole group of debug features when it should have been granted to one feature at a time.
Neither shows up as a crash. The chip works. The design simply exposes more than intended.
What an attacker gains
MITRE rates the likelihood of exploit as medium and lists a broad set of consequences: gain privileges or assume identity, bypass protection mechanisms, execute unauthorized code or commands, modify memory, and modify files or directories. It also lists loss of confidentiality, integrity, availability, authentication, authorization and accountability, with the note that the impact depends on which debug components are erroneously exposed.
Two observed examples in the record show the real-world flavor:
- CVE-2017-18347: incorrect access control in RDP Level 1 on STMicroelectronics STM32F0 series devices lets physically present attackers extract the protected firmware through a special sequence of Serial Wire Debug (SWD) commands. The cause is a race condition between full initialization of the SWD interface and the setup of flash protection.
- CVE-2020-1791: an improper authorization issue in several smartphones, caused by a logic-judging error, where a successful exploit could allow the attacker to switch to a third desktop after a series of operations in ADB mode.
How to find it
MITRE suggests two detection methods, both rated high effectiveness. One is an architecture or design review. The other is dynamic analysis with manual results interpretation. In both cases the guidance is the same: carry out appropriate post-silicon tests at various authorization levels to confirm debug components are properly chained and accessible only to users with appropriate credentials.
A practical test plan:
- List every debug component and the authorization level that should unlock it.
- At each level, attempt to reach every component, not only the intended ones.
- Record any component that responds at a level lower than designed.
- Repeat after every change to the debug interconnect.
How to fix it
The mitigation in the record is short. Ensure that debug components are properly chained and that their granularity is maintained at different authentication levels.
Turn that into design rules. Draw the debug chain as a diagram with authentication levels marked. Keep access to each hub tied to the level it belongs to. Review synthesis output against the diagram, since MITRE points at synthesis as a place where errors creep in.
Quick check
Why are post-silicon tests called out?
Design or synthesis errors can misconfigure the interconnect, so you need to test the real part at each authorization level.
What does granularity mean here?
How finely access to debug features is divided between authentication levels. If it is too coarse, a low level can reach features meant for a higher one.
