Comment by DamnInteresting

14 hours ago

> There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights.

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.

      1 reply →

  • 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.

  • 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.