Connect with us

Hi, what are you looking for?


Mobile & Wireless

Google Patches Nexus 6 Secure Boot Bypass

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.

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.

Advertisement. Scroll to continue reading.

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

Written By

Ionut Arghire is an international correspondent for SecurityWeek.

Click to comment


Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Join the session as we discuss the challenges and best practices for cybersecurity leaders managing cloud identities.


The AI Risk Summit brings together security and risk management executives, AI researchers, policy makers, software developers and influential business and government stakeholders.


People on the Move

Retired U.S. Army General and former NSA Director Paul M. Nakasone has joined the Board of Directors at OpenAI.

Jill Passalacqua has been appointed Chief Legal Officer at autonomous security solutions provider

Cisco has appointed Sean Duca as CISO and Practice Leader for the APJC region.

More People On The Move

Expert Insights