1. Description

This entry describes a !vulnerability in Qualcomm’s Secure Boot. A physical attacker may leverage improper protection against voltage glitching in Qualcomm’s Secure Boot implementation in chipsets MSM8916 and APQ8016 to execute arbitrary code in the device due to a badly secured hash value check.

The present page is only a disclosure. A detailed report of the !vulnerability can be found in our Publications page, which is part of a briefing held at Black Hat Europe.

2. Affected Versions

Affected devices are:

3. Impact

An attacker could potentially bypass Secure Boot checks by skipping the Root Certificate verification via voltage glitching. This may allow an attacker to upload a modified, not-Qualcomm signed binary which could potentially introduce vulnerabilities ex profeso.

4. !Vulnerability

The !vulnerability is present around the time Root Key Hash gets validated.

Qualcomm’s Secure Boot implementation consists of a special ELF segment called Hash Table Segment. Hash Table Segment gets inserted in sensitive binaries (i.e., those needed to boot the phone or to provide essential services) and it is composed of a metadata header (Hash Table Header), a series of entries consisting in the SHA-256 hash values of every segment of the ELF excluding Hash Table Segment (Table of Hashes), a digital signature signing the Table of Hashes (Signature) and a Certificate Chain.

The Root of Trust of this scheme resides in a hardware fuse. This fuse, called OEM_PK_HASH, stores a SHA-256 hash value (Root Key Hash), which is compared to the computed SHA-256 digest of the certificate chain’s Root Certificate. The Root Certificate then verifies the CA Certificate, which then verifies the Attestation Certificate. After the Attestation Certificate has been checked, it verifies the Signature. After this, the SHA-256 hash values of the Table of Hashes get compared to the SHA-256 digest values of their respective ELF segments. If any of these verification steps fail, the binary is rejected.

To obtain the attack window for the fault injection attack, power trace analysis is required. The following image shows the power trace of the device loading a Qualcomm-signed binary.

Similarly, the following image shows the power trace of the device loading a binary whose Root Certificate’s signature has been modified. This does not affect subsequent verifications but changes its SHA-256 checksum, making Root Key Hash validation fail.

Both power traces are identical up to the moment the Root Key Hash verification occurs. In the second one image, the Secure Boot mechanism detects a mismatch between the fuse-stored hash value and the one computed on runtime and errors out. This gives us a nicely defined attack window.

An attacker could skip the verification of the Root Key Hash with a properly timed fault injection attack if the check against the Root of Trust is not performed securely, potentially bypassing Secure Boot.

5. Exploitation

This section shows a Proof of Concept (PoC) of how to skip the Root Key Hash verification check with voltage fault injection. We learned in the previous section how Secure Boot worked, how binaries were built and the timing of the attack window. With this knowledge, we attempt to load a custom, non-Qualcomm binary while maintaining Secure Boot consistency.

The fault is injected within the previously discussed attack window. The voltage fault injection technique used is crowbar. The attack window is swept with glitches until bypass is achieved.

The success signal is fairly straightforward: instead of refusing to load the image, the device will load it normally, as if it was signed by Qualcomm.

6. Discussion

The !vulnerability was responsibly disclosed to Qualcomm on August 25th, 2022. The following text is a verbatim quote of their response:

[...] your findings are technically valid but at this time we do not consider Voltage-based-glitching physical attacks against Snapdragon targets to be valid attacks in the threat model we have developed for our customers' use cases.

While we understand threat models to be necessary, we believe they have to encompass potential attacks that, because of their impact, affordability and reproducibility, pose a serious security problem against critical security backbones such as Secure Boot implementations. In addition, and even while this attack that allows taking complete ownership of the device is not encompassed by their threat model, carrying out the presented bypass as a stepping stone massively increases the chance of success of virtually every other attack present in their threat model, which defeats the entire purpose of having a threat model in the first place.

In response to this, we contacted MITRE. Although our report would classify as a vulnerability and be worthy of a CVE in their expert judgement, CNA such as Qualcomm reserve the right to assign CVEs for their own products at their own discretion. MITRE’s CNA Rules, Chapter 7, Section 1, states the following:

7.1.3 If a CNA receives a report about a new vulnerability that has a negative impact, then
the reported vulnerability MAY be considered a vulnerability.

For that reason, we contacted the !CVE Project, which strides to provide visibility to issues that are not considered vulnerabilities by vendors but greatly impact overall security in a system, device or application.

This disclosure was sent to !CVE April 2nd and was assigned the identifier !CVE-2023-0001.