You can technically send then all the time and it is enough that they boot once. No need to know the time beforehand.
replyThe worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).
replyWhat we _can_ do, though, while the OS is running is detecting that bogus large ICMP packets are sent continuously. At least, this would be early warning that a reboot may be risky without disabling PXE.
At least some enterprise IDS /AFW could presumably have a signature configured for this traffic scenario.
replyBefore you manually configure a rule in your WAF you might as well just fix the vulnerability in the vulnerable component directly ^^
replyespecially in free/open source software like edk2
For a deployed server, yes, you’d probably need to first get inside their network, then using some other exploit or social engineering, cause the server to reboot and then provoke this vulnerability and gain a persistent shell on the server.
replyThis may sound like a movie-plot threat in 2020, but perhaps in 2026 it’s less unlikely?
There’s also the theft scenario, as indicated in the article, or the supply chain attack scenario. I don’t know how feasible it would be for a buyer to validate the integrity of the hardware they just racked up if they can’t trust secure boot?
It its anything like recent exploits, the whole internet is going to get hacked in 15 minutes... its a real exploit didn't you know?
replyThe chaining to get something like this to work is pretty up there.