There is a vulnerability in the manner in which the AT&T and Verizon Galaxy S4 Android smartphones do cryptographic checks of boot image signatures.
That means a security researcher, Dan Rosenberg of Azimuth Security, was able to exploit the flaw and upload his own unsigned kernel to the device.
An attacker could do the same and upload a malicious kernel or software and own the device. Rosenberg previously published work on Android devices built by Motorola where he was able to exploit a hole in the TrustZones deployed in the devices’ ARM processor.
TrustZones are security extensions to the processor that essentially run a secure kernel alongside the main kernel where sensitive applications such as mobile payment apps may execute. Motorola was using TrustZones to also control a lockdown of the bootloader.
The AT&T and Verizon devices use the Qualcomm APQ8064T chip which relies on its QFuses technology to implement a trusted boot sequence, Rosenberg said. The technology, which is a one-time configuration of hashes and keys, cryptographically verifies the next stage of boot up before it launches and then Samsung’s application secondary bootloader (APPSL) runs.
“This bootloader differs between locked and unlocked variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions,” Rosenberg said.
Rosenberg discovered the aboot bootloader on the devices is nearly identical to the open source Little Kernel bootloader project, which he said aided him in finding the functions that implement signature verification and booting of the Linux kernel. Once a particular boot function determines whether it is to load the main kernel or a recovery subsystem, it loads the appropriate partition into memory from the eMMC flash storage on the phone, Rosenberg said.
That programming logic has flaws, Rosenberg said.
“Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data,” Rosenberg said. “As a result, it’s possible to flash a maliciously crafted boot image whose header values cause aboot to read the kernel or ramdisk into physical memory directly on top of aboot itself.”
Signature checks occur after the kernel image loads, but if an attacker is able to access the process before this step, he can beat the signature validation. Aboot, for example, uses an open source implementation of RSA encryption for signature validation which compares the decrypted signature of the boot image to the SHA1 hash of the boot image, Rosenberg said.
Rosenberg said his exploit was a boot image where the ramdisk load address was equal to the address of the signature verification function in aboot. Rosenberg replaced the ramdisk with shellcode and flashed this image instead. Aboot reads the exploit image instead from flash and overwrites the signature check function with the shellcode.
“The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded,” Rosenberg said.