Kioxia: Open JTAG Debug Port
High7.3CVE-2024-7726 · Published Jul 16, 2024 · updated Aug 16, 2024
### Summary The Kioxia CM6, PM6 and PM7 disk drives are enterprise models supporting high security options such as Sanitize Instant Erase (SIE) and Self-Encrypting Drive (SED)/TCG Opal operation. Internally, the drives make use of a Kioxia TC58NC1132GTC disk controller SoC comprising multiple CPU cores. One of those cores is a security core (i.e. a security “sub-chip”/cryptographic module) that has received FIPS 140-2 and FIPS 140-3 NIST certification while the other 2 cores are 32-bit ARM Cortex-R5 cores used to execute the bootloader stages and main firmware. On the Kioxia CM6, PM6 and PM7 disk drives it was discovered that the 2 main CPU cores of the SoC can be accessed via an open JTAG debug port that is exposed on the drive’s circuit board. Due to the wide cutout of the enclosures, the JTAG port can be accessed without having to open the disk enclosure. Utilizing the JTAG debug port, an attacker with (temporary) physical access can get full access to the firmware and memory on the 2 main CPU cores within the drive including the execution of arbitrary code, the modification of firmware execution flow and data or bypassing the firmware signature verification during boot-up. In ...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| CM6, PM6, PM7 Product | all versions | No fix yet |
Details and references
### Summary The Kioxia CM6, PM6 and PM7 disk drives are enterprise models supporting high security options such as Sanitize Instant Erase (SIE) and Self-Encrypting Drive (SED)/TCG Opal operation. Internally, the drives make use of a Kioxia TC58NC1132GTC disk controller SoC comprising multiple CPU cores. One of those cores is a security core (i.e. a security “sub-chip”/cryptographic module) that has received FIPS 140-2 and FIPS 140-3 NIST certification while the other 2 cores are 32-bit ARM Cortex-R5 cores used to execute the bootloader stages and main firmware. On the Kioxia CM6, PM6 and PM7 disk drives it was discovered that the 2 main CPU cores of the SoC can be accessed via an open JTAG debug port that is exposed on the drive’s circuit board. Due to the wide cutout of the enclosures, the JTAG port can be accessed without having to open the disk enclosure. Utilizing the JTAG debug port, an attacker with (temporary) physical access can get full access to the firmware and memory on the 2 main CPU cores within the drive including the execution of arbitrary code, the modification of firmware execution flow and data or bypassing the firmware signature verification during boot-up. In the worst case, an attacker could gain persistence within the drive firmware by uploading a modified firmware update and utilizing JTAG to bypass the RSA firmware update signature verification. However, since the firmware stored on the drive is also protected through a MAC code with a shared secret, in this scenario the attacker would need to know the shared secret as well to compute a correct MAC code for the changed firmware. While the PM drive series relies on SAS interfacing, the CM drive series is directly attached to the PCIe bus and uses NVMe instead. In the worst case, we believe an attacker could use malicious firmware within the drive to manipulate encryption/sanitization functionality or attack the host and other devices attached to the PCIe bus via DMA attacks. ### Severity High - An attacker with (temporary) physical access can get full access to the firmware and memory within the drive including the execution of arbitrary code, the modification of the firmware execution flow and data or bypassing the RSA firmware signature verification during a firmware upgrade. However, true persistence in firmware is only feasible if the attacker is also in possession of the shared secret that is required to compute a correct MAC code for the changed firmware. ### Proof of Concept By utilizing a low-cost ARM JTAG debug probe and open source JTAG tools such as openocd, an attacker can access the JTAG chain. On the JTAG chain are the JTAG-DP Debug Ports for the CPU cores (0x4BA00477, IRLen: 04, CoreSight JTAG-DP). The first two out of these 3 cores can be accessed via JTAG. We utilized the following openocd configuration to access the JTAG debug port: ``` # Kioxia CM6 Debug Port source [find interface/jlink.cfg] source [find target/swj-dp.tcl] # This is using the name on the SoC if { [info exists CHIPNAME] } { set _CHIPNAME $CHIPNAME } else { set _CHIPNAME tc58nc1132gtc } # This is the TAP ID that we discovered in the previous step if { [info exists CPUTAPID] } { set _CPUTAPID $CPUTAPID } else { set _CPUTAPID 0x4ba00477 } # Set the speed of our adapter adapter speed 40000 # We are indeed using JTAG transport select jtag # We don't have a SRST pin, only TRST it would seem reset_config trst_only # listen on all interfaces so that we can connect remotely bindto 0.0.0.0 # Here we create the JTAG TAP/DAP, defining the location and characteristics of our DAP #swj_newdap $_CHIPNAME cpu0 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID #dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu0 #set _TARGETNAME $_CHIPNAME.cpu swj_newdap $_CHIPNAME cpu0 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID swj_newdap $_CHIPNAME cpu1 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-
- CVSS 3.1
- CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-1191
More Google advisories
All Google| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Aug 142024 | LibRaw: Out of bounds write in LibRaw::sonyParseSR2 | Medium | No fix yet |
| Jul 242024 | TurboMeeting: Post-Authentication Command Injection | High7.2 | No fix yet |
| Jul 242024 | TurboMeeting: Insecure Password Reset Mechanism | High8.1 | No fix yet |
| Jul 242024 | TurboMeeting: Boolean-based SQL Injection | Critical9.8 | None |
| Jul 162024 | Linux Kernel: Vulnerability in the eBPF verifier register limit tracking | Medium | No fix yet |
| Jun 252024 | Nuvoton / Dell iDRAC: RootBlock | Critical | 10.10.19+2 more |