Remix.run Logo
▲ DamnInteresting 9 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.

▲bediger4000 8 hours ago | parent [-]

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.

▲mjg59 a minute ago | parent | next [-]

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.

▲octoberfranklin 4 hours ago | parent | prev | next [-]

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 an hour ago | parent [-]

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

▲amluto 4 hours ago | parent | prev [-]

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.