You also need to have sufficiently infiltrated the target’s local network to masquerade as a PXE server, and be in a position to force a server to reboot / just wait for one to reboot. Yes, a few places have large, fairly open networks with a lot of devices configure to PXE boot and they should apply the update before the next reboot, but vast majority of people, no issue at all.
ipxe with appropriate kernels, images and config files was a bit more difficult.
Used it for over a decade at work… installed thousands of operating systems, headless and diskless crypto miners and recover tools.
Same, ran FOG for a long time, but setting it up appropriately and for others to use on a corporate R&D network I did not have full control over was fiddly.
It’s how I installed Arch btw on my desktop, tiny boot image basically downloads the installer into RAM - NetBoot.
But yeah, if you’ve got a computer that’s old enough to be fully supported yet new enough to have the UEFI for hardware, an ethernet network which is robust enough to download full system images on every restart yet simple enough for the firmware to understand, and tonnes of memory free to hold the whole OS at all times, and you can tolerate the fact that restarts take ages, then it works great.
I once ran out of functional flash drives and DVDs, so I SSHed into a home router, made a new dnsmasq config in the tmpfs, then killed dnsmasq and quickly ran it again but with the new config before the pile of scripts acting as init noticed and rebooted everything. I pointed it to that netboot dot xyz piece of shit. It did work, though.
Since it is remote execution in UEFI, does that mean if you compromised the system you can now use this to install a backdoor in the firmware so wiping and reinstalling won’t help?
I think the detailed description of this vulnerability described it as non-persistent in UEFI, but that you could install something that runs before secure boot that would be persistent. I think that’s splitting hairs, though - if you’ve been compromised by someone that has the skills to pull this exploit off, then they can probably chain something else into it now that they’ve got basically bare-metal access.
You also need to have sufficiently infiltrated the target’s local network to masquerade as a PXE server, and be in a position to force a server to reboot / just wait for one to reboot. Yes, a few places have large, fairly open networks with a lot of devices configure to PXE boot and they should apply the update before the next reboot, but vast majority of people, no issue at all.
If a hacker can get PXE boot working reliably I’d hire them
dhcp and tftp. pretty easy.
ipxe with appropriate kernels, images and config files was a bit more difficult. Used it for over a decade at work… installed thousands of operating systems, headless and diskless crypto miners and recover tools.
Same, ran FOG for a long time, but setting it up appropriately and for others to use on a corporate R&D network I did not have full control over was fiddly.
It’s how I installed Arch btw on my desktop, tiny boot image basically downloads the installer into RAM - NetBoot.
But yeah, if you’ve got a computer that’s old enough to be fully supported yet new enough to have the UEFI for hardware, an ethernet network which is robust enough to download full system images on every restart yet simple enough for the firmware to understand, and tonnes of memory free to hold the whole OS at all times, and you can tolerate the fact that restarts take ages, then it works great.
Reminds me of the old adage: How do you figure out if someone is an Arch user… 😁
They’ll tell you, and they’ll give you a new installation method.
Seriously though, that wiki entry is pretty neat.
I once ran out of functional flash drives and DVDs, so I SSHed into a home router, made a new dnsmasq config in the tmpfs, then killed dnsmasq and quickly ran it again but with the new config before the pile of scripts acting as init noticed and rebooted everything. I pointed it to that netboot dot xyz piece of shit. It did work, though.
Since it is remote execution in UEFI, does that mean if you compromised the system you can now use this to install a backdoor in the firmware so wiping and reinstalling won’t help?
I think the detailed description of this vulnerability described it as non-persistent in UEFI, but that you could install something that runs before secure boot that would be persistent. I think that’s splitting hairs, though - if you’ve been compromised by someone that has the skills to pull this exploit off, then they can probably chain something else into it now that they’ve got basically bare-metal access.