SymmetricalDataSecurity: Android security: Multiple bootloader bugs found in major chipset vendors' code

Monday, September 4, 2017

Android security: Multiple bootloader bugs found in major chipset vendors' code

The researchers have found flaws in bootloaders from a number of makers but note that the design of Huawei's bootloader makes its bugs "quite severe".

Image: James Martin/CNET

Smartphone bootloader firmware should be secure even if the operating system is compromised. But researchers have found five flaws in major chipset vendors' code that leave the process vulnerable.

The vulnerabilities have been found by a group of researchers from the University of California, Santa Barbara, who've built a tool called BootStomp to automatically detect security flaws in bootloaders, which load the OS kernel when devices are turned on.

The tool identified six zero-day flaws in two bootloaders after analyzing code from four large chipset makers, including Qualcomm, MediaTek, Nvidia, and Huawei. They also rediscovered a known flaw in a Qualcomm bootloader using the tool. Five of the six new-found flaws have been confirmed by the vendors.

As they note, bootloaders are difficult to analyze with software partly because they're closed source, hardware specific, and hard to reverse-engineer. BootStomp has been built to overcome those difficulties.

"The goal of BootStomp is to automatically identify security vulnerabilities that are related to the (mis)use of attacker-controlled non-volatile memory, trusted by the bootloader's code," the researchers explain.

"In particular, we envision using our system as an automatic system that, given a bootloader as input, outputs a number of alerts that could signal the presence of security vulnerabilities. Then, human analysts can analyze these alerts and quickly determine whether the highlighted functionality indeed constitutes a security threat."

Ensuring the integrity of bootloaders is critical to Google's Verified Boot and ARM's Trusted Boot, where bootloaders verify the integrity of each other to create a so-called 'chain of trust'. If someone tampers with bootloader components, a kernel or the file system image, the device should be unusable.

As the researchers note, this sequence should be a rigid process that prevents a compromise even if the Android OS itself has been hacked. However, hardware vendors are given the flexibility to implement bootloaders differently to suit their products.

Using BootStomp, the researchers have found 36 potentially dangerous paths during bootloading sequences, of which over a third were vulnerabilities.

"Some of these vulnerabilities would allow an adversary with root privileges on the Android OS to execute arbitrary code as part of the bootloader. This compromises the entire chain of trust, enabling malicious capabilities such as access to the code and storage normally restricted to TrustZone, and to perform permanent denial-of-service attacks -- ie, device bricking.

"Our tool also identified two bootloaders that can be unlocked by an attacker with root privileges on the OS."

For the paper, the researchers assumed the attacker can control any content of non-volatile storage on a device, which could happen if an attacker has gained root on it.

The five bootloaders were from devices using three different chipset families, including Huawei P8 ALE-L23 with the Huawei/HiSilicon chipset, a Sony Xperia XA with a MediaTek chipset, and Nexus 9 with Nvidia's Tegra chipset. They also looked at a new and old version of Qualcomm's bootloader.

The known bug, CVE-2014-9798, is a denial of service affecting an old version of Qualcomm's bootloader. The new bugs included one in Nvidia's bootloader, and five affecting the Huawei Android bootloader.

The researchers note that the design of Huawei's bootloader makes the bugs "quite severe" because they would allow an attacker to break the chain of trust, and gain persistence in the device that would be difficult to detect by a user.

The paper was first reported by Bleeping Computer based on a recent presentation at the USENIX conference in Vancouver, Canada.