No, it’s an actual attack. But we don’t know for sure if it’s being exploited actively in the wild. This vulnerability has existed ever since PCs adopted UEFI (~2006).
I’ll answer because I found the information. It appears that the attacker would need to rely on physical access to the machine OR another exploit that lets them access the computer remotely.
Or they could just get you to execute the command without your knowledge (eg: all the people who just blindly copy-paste commands, or pipe scripts from the net into sudo). Or it could be a compromised github account/repo (supply-chain attack). Or even the ol’ techsupport scam where they get gullible users to install stuff…
They need to be able to place a malicious file in EFI boot partition or in an unsigned section of a firmware update. Holes in the libraries that parse images for display on preboot.
No way to know. It depends on how whoever did your firmware handled it. The idea is that there’s an overflow or something in the image parser. If the person writing your firmware code still parses the image even if it’s not displayed, you’d still get the pointy end. (and at that point, they’re bypassing secure boot)
Don’t sweat it too much, the file has to get there somehow before it can even be an issue. So someone needs to write to your UEFI partition or get you to flash a bad bios. It’s just an inside vector not a direct attack. I’ll be good for people to update their damn image processing, but the likely hood of getting shived in the wild is pretty low.
I wonder… could one put their UEFI partition on a flash drive, then remove after booting? Or just dismount the partition, but physical separation sounds better
So, this is proof of concept, not an actual attack at this time. Correct?
No, it’s an actual attack. But we don’t know for sure if it’s being exploited actively in the wild. This vulnerability has existed ever since PCs adopted UEFI (~2006).
More importantly, does the attacker need physical access to the computer or can this be performed over the Internet/local network?
I’ll answer because I found the information. It appears that the attacker would need to rely on physical access to the machine OR another exploit that lets them access the computer remotely.
So the best security is still keeping your computer behind a locked door and not clicking on suspicious stuff?
The best security is keeping it in box, removing the battery, and never turning it on. /j
Maybe I should hire an Amish guy as a consultant for IT. Those guys never get hacked.
Beg to disagree. See: “Amish Mafia.”
Or they could just get you to execute the command without your knowledge (eg: all the people who just blindly copy-paste commands, or pipe scripts from the net into
sudo). Or it could be a compromised github account/repo (supply-chain attack). Or even the ol’ techsupport scam where they get gullible users to install stuff…They need to be able to place a malicious file in EFI boot partition or in an unsigned section of a firmware update. Holes in the libraries that parse images for display on preboot.
What if I disable UEFI splash screen? I always do that if possible. Not due to this, but because I prefer a bunch of text over a lame logo.
No way to know. It depends on how whoever did your firmware handled it. The idea is that there’s an overflow or something in the image parser. If the person writing your firmware code still parses the image even if it’s not displayed, you’d still get the pointy end. (and at that point, they’re bypassing secure boot)
Don’t sweat it too much, the file has to get there somehow before it can even be an issue. So someone needs to write to your UEFI partition or get you to flash a bad bios. It’s just an inside vector not a direct attack. I’ll be good for people to update their damn image processing, but the likely hood of getting shived in the wild is pretty low.
I wonder… could one put their UEFI partition on a flash drive, then remove after booting? Or just dismount the partition, but physical separation sounds better