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