Hacker News

points by DamnInteresting 2 days ago | 0 comments

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

[–] bediger4000 2 days 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.

[–] michaelt 2 days ago

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.

[–] crote 2 days ago

Some thin clients boot from PXE so they can forego local storage completely. Being able to update the entire fleet and completely prevent any kind of local changes with a simple reboot is a gamechanger for maintainability: you can be 100% certain that every "installation" is absolutely identical.

It also wasn't uncommon to install a server's hypervisor to a USB flash drive, or a tiny local SSD. Server motherboards with internal USB-A ports (not headers, the entire port) were quite common, and there were even IDE flash drives you could plug straight into the motherboard. This allowed you to completely dedicate the regular storage to the client VMs. I would not be surprised if that same market also used PXE for the same reason in larger installations.

[–] jeroenhd 1 day ago

PXE can be great for stacks of virtual machines or thin client setups.

PXE has been enabled by default on most devices I bought, but only after USB and SSD boot failed, so in practice it's not really something you're going to see a lot of.

[–] mjg59 2 days ago

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.

[–] reorder9695 2 days ago

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.

[–] mjg59 2 days ago

Yup, if there's no passphrase involved.

[–] rocqua 1 day ago

Even if there is a passphrase, this would likely allow for brute-forcing it.

[–] mjg59 1 day ago

No, you'll still have the TPM's dictionary attack lockout.

[–] octoberfranklin 2 days ago

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.

[–] vintermann 2 days ago

Do any of the locked down consoles or phones use a vulnerable UEFI implementation by any chance?

[–] mschuster91 2 days ago

Phones most commonly use their own bootloader stack.

[–] mjg59 2 days ago

UEFI is pretty common on phones now, but it's unlikely that any of them are running this network stack there.

[–] fn-mote 1 day ago

Exactly. No phones have PXE boot enabled, regardless of the rest.

[–] yjftsjthsd-h 2 days ago

Is it? I'd like a UEFI phone booting GNU/Linux but last I looked it was a bunch of hacky aftermarket firmwares.

PS your profile links a blog that says you moved

[–] mjg59 2 days ago

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.

And thanks! Updated my profile.

[–] amluto 2 days ago

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.

[–] kikdij 2 days ago

I don't know where Ars Technica got that from, though. The initial advisory [1] says:

> The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance.

[1] https://github.com/tianocore/edk2/security/advisories/GHSA-9...

[–] adrian_b 1 day ago

If such an ICMP error message comes from outside, the firewalls with stricter rules will reject it, because it does not correspond to packets sent by the victim computer.

Moreover, Ethernet booting is done usually from separate management networks to which only the administrators are connected, on which also other vulnerable protocols, like IPMI, are used, not from the main network that may have an Internet gateway.

[–] izacus 2 days ago

This is literally some security people crying wolf until everyone just stops listening to them.

[–] syshyk 2 days ago

They're admitting it though, at least?