One of the vulnerabilities addressed by Google in its May 2017 security patches allowed the bypass of Nexus 6’s Secure Boot through kernel command-line injection, HCL Technologies researchers reveal.
By exploiting the flaw, an attacker with physical access to the device or one with authorized-ADB/fastboot USB access to the (bootloader-locked) device could gain unrestricted root privileges and “completely own the user space.” For that, the attacker would have to load a tampered or malicious initramfs image.
Security researcher Roee Hay also explains that, because the exploitation doesn’t lead to a factory reset, user data remains intact and still encrypted. The vulnerability is tracked as CVE-2016-10277.
The issue, Hay says, is a continuation of CVE-2016-8467, a High risk vulnerability affecting the Nexus 6/6P bootloader, and which was addressed in Google’s January 2017 security patches. The exploit abused fastboot commands to change the androidboot.mode argument in the kernel command line and was addressed by hardening the bootloader.
“Just before Google released the patch, we had discovered way to bypass it on Nexus 6,” the researcher notes.
Because the fsg-id, carrier and console arguments in Nexus 6’s bootloader can be controlled through the fastboot interface (even if the bootloader is locked), one could pass arbitrary kernel command line arguments if the bootloader didn’t sanitize said three arguments. The researchers also found a series of parameters that can contain arbitrary values and which propagate to the kernel command line.
After previously discovering they could tamper with the bootmode, the researchers focused on finding ways to compromise a device further by inserting arbitrary arguments into the command line. Eventually, they discovered that they could defeat Secure Boot by being able to control a single argument.
The exploit relies on initramfs, a cpio (gzipped) archive that gets loaded into rootfs (a RAM filesystem) during the Linux kernel initialization. The bootloader prepares the kernel command line and initramfs parameters for the Linux kernel in the Device Tree Blob, and then transfers execution to the Linux kernel.
A kernel_init function executes the first userspace process called /init, and a kernel command line argument rdinit can override this default value, but exploitation wasn’t effective, mainly because the Nexus 6 initramfs doesn’t contain a large enough set of binaries, the researcher notes.
“Interestingly, we’ve realized that in arm, it is also possible to control, through a kernel command line argument initrd, the physical address where the initramfs is loaded from by the kernel,” Hay says.
By overriding the default values provided by the bootloader in the Device Tree Blob, the researchers caused the Kernel to crash. Next, they focused on loading their own initramfs archive to the device’s memory, through fastboot.
“Note that the Linux Kernel does not re-verify the authenticity of initramfs, it relies on the bootloader to do that, so if we manage to put a tampered initramfs at the controlled phys_initrd_start physical address, the kernel will indeed populate it into rootfs,” the researcher explains.
Fastboot offers a download mechanism via USB and, because the operation is available even on locked bootloaders, an attacker can abuse it to load a tampered initramfs on the device. The exploit is then successful if the bootloader and Kernel don’t overwrite the data before initramfs is populated into rootfs.
The security researchers created a Proof-of-Concept initramfs and made it publicly available on GitHub. Upon gaining full control of rootfs, an attacker can create a malicious /vendor folder, where firmware images of various SoCs available on the board would normally be saved.
“Kernel drivers usually consume these images upon initialization, and update their SoC counterparts if needed. Hence, the attacker could flash unsigned firmware images. We haven’t checked if there are such, but from our experience with other devices, there are. As for signed ones, downgrade attacks might be possible as well,” Hay says.
Google addressed the issue in the May 2017 set of monthly patches by setting the bootloader to sanitize the fsg-id, carrier and console config arguments.
Related: Google Patches High Risk Vulnerability in Android Bootloader
Related: Google Patches More Critical Flaws in Android Mediaserver
Tags: