Comment by jeroenhd
13 days ago
Their low-level bootloader code contains a vulnerability that allows an attacker with physical access to boot an OS of their choice.
Android's normal bootloader unlock procedure allows for doing so, but ensures that the data partition (or the encryption keys therefore) are wiped so that a border guard at the airport can't just Cellebrite the phone open.
Without downgrade protection, the low-level recovery protocol built into Qualcomm chips would permit the attacker to load an old, vulnerable version of the software, which has been properly signed and everything, and still exploit it. By preventing downgrades through eFuses, this avenue of attack can be prevented.
This does not actually prevent running custom ROMs, necessarily. This does prevent older custom ROMs. Custom ROMs developed with the new bootloader/firmware/etc should still boot fine.
This is why the linked article states:
> The community recommendation is that users who have updated should not flash any custom ROM until developers explicitly announce support for fused devices with the new firmware base.
Once ROM developers update their ROMs, the custom ROM situation should be fine again.
That makes sense, but how would an attacker flash an older version of the firmware in the first place? Don't you need developer options and unlocking + debugging enabled?
Qualcomm phones come with a special mode (https://en.wikipedia.org/wiki/Qualcomm_EDL_mode) that allows devices to get unbricked even after you break the normal user-updatable "bootloader" on flash completely.
This feature doesn't allow unlocking the bootloader (as in, execute a custom ROM), it's designed to install factory-signed code. However, using it to "restore" an old, vulnerable factory code would obviously cause issues.
Open the case and pogo pin on a flash programmer directly to the pins of the flash chip.
Sophisticated actors (think state-level actors like a border agent who insists on taking your phone to a back room for "inspection" while you wait at customs) can and will develop specialized tooling to help them do this very quickly.
thank you for this, I have a follow up question: Now an attacker can not install an old, vulnerable version. But couldn't they just install a new, vulnerable version? Is there something that enforces encryption key deletion in one case and not the other?
AFAIK the signature mechanism hasn't been defeated, so the attacker can only load software signed by the factory keys.
Which includes old, vulnerable versions and all patched, newer versions. By burning in the minimum version, the old code now refuses to boot before it can be exploited.
This is standard practice for low-level bootloader attacks against things like consoles and some other phone brands.