CWE-1244 is a design weakness in products with physical debug or test interfaces that support multiple access levels. When an internal asset is given the wrong level, an untrusted debug agent can reach it. It hits SoC designers, board makers and anyone who ships a device with JTAG or a similar port left reachable.
How it happens
Debug authorization is rarely all or nothing. It can depend on the debugger's credentials, such as a password or a challenge, but also on the system state or boot stage. A common design allows full debug access early after reset, so that no previous session data is visible to the authenticated debugger, and then restricts access as boot proceeds.
The weakness appears when an asset's access level does not match the state the system is in. Each boot stage and each change of system state needs its own check that the asset has the right level.
MITRE lists CVE-2019-18827 as an observed example. JTAG access is disabled after the ROM code runs, but before the ROM code executes, JTAG access is open. A user at that point gets full system access, can modify the boot flow and can disclose CPU data including encryption keys. In MITRE's register example, the shield bit had no default value at power up, so the debugger was enabled until the system had booted. The Gold page for CVE-2019-18827 has the record.
A second MITRE example, from a buggy contest SoC, covers debug access gated by a privilege check plus a password check. The point of that design is that both conditions must hold before the processor enters debug mode.
What an attacker gains
The consequences in the record cover three areas:
- Confidentiality. Reading memory and obtaining sensitive information from the internal asset with a debugger.
- Integrity. Modifying memory.
- Authorization and access control. Gaining privileges or assuming identity, and bypassing protection mechanisms.
How to find it
MITRE lists one detection approach, manual analysis, rated moderate in effectiveness.
- Check two devices for the passcode that authenticates access to JTAG and debug ports. If the passcodes are missing or are the same on both, change the design and retest.
- Check whether communications over the JTAG or debug port are encrypted. If not, fix the design and retest.
Add to that a state by state review. For every boot stage, write down what debug level is active and which assets that level exposes. Gaps tend to show up in the earliest stages, before the first trusted code runs.
How to fix it
MITRE's mitigations:
- For security-sensitive assets reachable over debug or test interfaces, only allow trusted agents. Effectiveness is rated high.
- Apply blinding or masking techniques in strategic areas. Effectiveness is limited.
- Add shielding or tamper-resistant protections to raise the difficulty and cost of reaching debug and test interfaces. Effectiveness is limited.
For the register example, the entry's fix is to set the default of the shield bit to 1, so that JTAG is disabled at system reset rather than enabled until software turns it off.
Quick check
Why does boot stage matter for debug access?
Debug authorization can depend on system state. An asset that is safe to expose at one stage may be dangerous at another, so each stage needs its own correct access level.
What default should a JTAG shield bit have?
MITRE's example says the default should be set so JTAG is disabled at reset, so the port is closed until something deliberately and safely opens it.
