A white hat researcher by the name of Triszka Balázs recently identified a security vulnerability that reportedly “affect[ed] every single” Tegra-based device released so far – except for the Nintendo Switch. As Balázs points out, the Switch utilizes its own custom bootloader.
“After checking the magic in the header, the nvtboot reads the entire TBC partition (size stored in the GPT) where LoadAddressInsecure points to,” he states on GitHub. “If that points to nvtboot in the memory, it’s possible to overwrite it, leading to unsigned code execution on the BPMP. This can be used to load the rest of the bootchain without checking the signatures.”
In addition to revealing the vulnerability, Balázs created a proof-of-concept (PoC) dubbed Selfblow (using blobs from the Shield TV r30 release) to exploit the above-mentioned vulnerability.
“In this example, running the flash_exploit.sh it can be flashed to the Jetson TX1,” he adds. “After booting the TX1 it will print a ‘Secure boot is broken!\n’ message to the uart0 before going into an infinite loop.”
As Tom Spring of ThreatPost observes, the Tegra chipset vulnerability could have potentially opened the door for a wide range of attacks, including device hijacking or siphoning of data. Although it is unclear how many Tegra chips utilize the vulnerable framework, Balázs told the publication his PoC can flash (or reprogram) Tegra chips to run Jetson TX1.
“One way to exploit the vulnerability is for a local adversary to access and write to the chip’s embedded MultiMediaCard (eMMC),” writes Spring. “If that can’t be done at the local level, it can be done via [Balázs’] PoC (Selfblow). The PoC, for example, can be delivered via a malicious Android app or booby-trapped website that can write to the eMMC.”
NVIDIA responded to the Selfblow reveal by releasing software security updates for Jetson TX1 in the NVIDIA Tegra Linux Driver Package (L4T).
“NVIDIA Tegra bootloader contains a vulnerability in nvtboot in which the nvtboot-cpu image is loaded without the load address first being validated, which may lead to code execution, denial of service, or escalation of privileges,” the company states in an official security bulletin. “The update addresses issues that may lead to code execution, denial of service, or escalation of privileges.”
As we’ve previously discussed on Rambus Press, semiconductor security is dynamic and should evolve organically to intelligently and proactively protect changing workloads and applications. Indeed, silicon threat models and cyber-attack vectors rarely remain static. From our perspective, a fully programmable hardware-based security co-processor can help protect silicon against exploits like Selfblow. Indeed, a physically siloed security co-processor can offer truly secure boot capabilities, secure execution of user applications, tamper detection and protection as well as secure storage and handling of keys and security assets.
Interested in learning more about how an independent security co-processor can help prevent semiconductor vulnerabilities and protect against exploits like Selfblow? You can check out our CryptoManager Root of Trust product page here.