Comment by bediger4000
13 hours ago
This one seems weird. PXE-boot is such a fragile process in and off itself this doesn't strike me as end-of-the-world. If an attacker has enough presence on your network to send a targeted ICMP packet, they almost certainly could also fool around with your PXE-booting servers some other way.
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.
Would 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.
Yup, if there's no passphrase involved.
Yes - 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"
Which 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.
This 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?
Phones most commonly use their own bootloader stack.
3 replies →
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.