Yeah I'm actually not terribly worried about the server scenario, but having a way to get code exec in the firmware lets you defeat measured boot, which means this is a Bitlocker bypass in the default config.
replyWould this mean any TPM based decryption keys could potentially be compromised in this kind of attack? E.g. when they're used for LUKS disk encryption.
replyYup, if there's no passphrase involved.
replyYes - all the times I've seen PXE boot used, the usage has been "Hold F12 during boot to reformat the disk and re-install the OS from scratch"
replyWhich is something that happens inside a trust boundary. After all, if an untrusted third party gets to install your OS it's game over, UEFI bug or not.
And consumer devices often don't have a network card - or come with PXE disabled in the BIOS.
Yeah but that just lets them replace the OS that gets booted.
replyThis gives the attacker access at the UEFI level and above -- they can use it to produce false attestations.
Do any of the locked down consoles or phones use a vulnerable UEFI implementation by any chance?
replyPhones most commonly use their own bootloader stack.
replyUEFI is pretty common on phones now, but it's unlikely that any of them are running this network stack there.
replyIs it? I'd like a UEFI phone booting GNU/Linux but last I looked it was a bunch of hacky aftermarket firmwares.
replyPS your profile links a blog that says you moved
It being UEFI doesn't mean it's a standard platform, there's no ACPI and you're going to need a custom kernel that targets that specific device. UEFI alone isn't enough to support booting a generic OS.
replyAnd thanks! Updated my profile.
Except that a sensible deployment of PXE boot would also have the servers attest to their state prior to giving them any secrets. This vulnerability breaks this workflow.
reply