Those of you who like to tinker and jailbreak Android phones should take notice of some new research conducted on Samsung Galaxy S4 Android devices shipped by AT&T and Verizon. Both device makers ship the Galaxy S4 smartphones with a locked down bootloader that prevents users from uploading custom kernels or from making modifications to software on the phone.
Azimuth Security researcher Dan Rosenberg has found a vulnerability in the manner in which the devices do cryptographic checks of boot image signatures and 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 has 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 are built on 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’s launched 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 that 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 is flawed, 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 are done after the kernel image is loaded, 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.
