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-id $_CPUTAPID
swj_newdap $_CHIPNAME cpu2 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
dap create $_CHIPNAME.cpu0 -chain-position $_CHIPNAME.cpu0
dap create $_CHIPNAME.cpu1 -chain-position $_CHIPNAME.cpu1
dap create $_CHIPNAME.cpu2 -chain-position $_CHIPNAME.cpu2
set _TARGETNAME_0 $_CHIPNAME.t0
set _TARGETNAME_1 $_CHIPNAME.t1
set _TARGETNAME_2 $_CHIPNAME.t2
target create $_TARGETNAME_0 cortex_r4 -endian little -dap $_CHIPNAME.cpu0
target create $_TARGETNAME_1 cortex_r4 -endian little -dap $_CHIPNAME.cpu1
target create $_TARGETNAME_2 cortex_r4 -endian little -dap $_CHIPNAME.cpu2
init
# reset init
jlink hwstatus
dap info 0
dap info 1
dap info 2
Further Analysis
If you wish to add more context or information, we recommend adding it after the critical sections mentioned here..
Timeline
Date reported: 04/04/2024
Date fixed:
Date disclosed: 07/13/2024
mkammerstetter Finder
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:
Further Analysis
If you wish to add more context or information, we recommend adding it after the critical sections mentioned here..
Timeline
Date reported: 04/04/2024
Date fixed:
Date disclosed: 07/13/2024