Skip to content

Latest commit

 

History

History
79 lines (67 loc) · 3.57 KB

ALEPH-2017028.md

File metadata and controls

79 lines (67 loc) · 3.57 KB
layout title timeline qpsiir severity product credit alephid date vendor
vuln
Qualcomm EDL Firehose Programmers Peek and Poke Primitives
type date
add
2017-11-09
type date
vendor-track
2017-12-01
type date
vendor-ack
2017-12-01
type date arg
report
2017-12-01
Qualcomm
date type msg
2018-01-03
vendor-msg
The problem is caused by customizations from OEMs...Our Boot ROM supports anti-rollback mechanism for the firehose image.
type date
release
2018-01-22
909
critical
Qualcomm
roeeh
noamh
ALEPH-2017028
2018-01-22
Qualcomm

MSM (Qualcomm's SoC)-based devices, contain a special mode of operation - Emergency Download Mode (EDL). In this mode, the device identifies itself as Qualcomm HS-USB 9008 through USB. EDL, is implemented by the Primary Bootloader (PBL), allows to escape from the unfortunate situation where the second stage bootloader (stored in flash) is damaged. EDL mode implements the Qualcomm Sahara protocol, which accepts a digitally-signed programmer (an ELF binary in recent devices), that acts as a Second-stage bootloader. Modern such programmers implement the Firehose protocol.

[Primary Bootloader (PBL)]
|
`---EDL---.
           [Programmer (Firehose)]
           `- Commands (through USB)

For details on how to get into EDL, please see our blog post.

Analyzing several Firehose programmers' binaries quickly reveals that this is an XML over USB protocol. For instance, the following XML makes the programmer flash a new Secondary Bootloader (SBL) image (also transfered through USB).

<?xml version="1.0" ?>
<data>
  <program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="sbl1.bin"
           label="sbl1" num_partition_sectors="1024" physical_partition_number="0"
           size_in_KB="512.0" sparse="false"
           start_byte_hex="0xc082000" start_sector="394256"/>
</data>

Loading the programmer with IDA, quickly revealed that our obtained Firehose programmers also support the peek and poke tags, with the following format:

32-bit programmers:

<peek address64="ADDR" SizeInBytes="SIZE"/>
<poke address64="ADDR" SizeInBytes="SIZE" value="VALUE"/>

64-bit programmers:

<peek address64="ADDR" size_in_bytes="SIZE"/>
<poke address64="ADDR" size_in_bytes="SIZE" value64="VALUE"/>

These allow for arbitrary code execution in the context of the programmer, as demonstrated in our blog post.

Using these primitives we managed to:

  1. Create an exploitation and research framework capable of tracing the execution of Firehose programmers, and the rest of the bootloader chain, specifically on Nokia 6. (Other devices require further research.)
  2. Obtain and reverse-engineer the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using our research framework.
  3. Obtain the RPM & Modem PBLs of Nexus 6P (MSM8994).
  4. Manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is applicable to Nokia 5 as well, although unverified.

As for remediation, vendors with leaked programmers should use Qualcomm's Anti-Rollback mechanism, if applicable, in order to prevent them from being loaded by the Boot ROM (PBL)