- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
“Whether a proof of concept or not, Bootkitty marks an interesting move forward in the UEFI threat landscape, breaking the belief about modern UEFI bootkits being Windows-exclusive threats,” ESET researchers wrote. “Even though the current version from VirusTotal does not, at the moment, represent a real threat to the majority of Linux systems, it emphasizes the necessity of being prepared for potential future threats.”
You must log in or register to comment.
@marcan@treehouse.systems (Hector Martin from Asahi Linux) said the following on Mastodon:
Ars headline: “Found in the wild: The world’s first unkillable UEFI bootkit for Linux”
Article then proceeds to describe a toy GRUB wrapper bootkit that has nothing to do with UEFI firmware (other than running on UEFI systems like any other UEFI bootloader), does not persist in UEFI firmware whatsoever (it just is installed in the ESP partition on disk), and can be killed by not just a drive swap, but any OS reinstall, and even simply a GRUB update/reinstall.
And which looks like a toy demo from every angle, that any experienced security researcher could have cooked up in a couple afternoons. Hardcoded kernel patch offsets for a single specific Ubuntu kernel build and all. No novel techniques in use. This could have even been a homework exercise as far as I’m concerned.
In fact, it has an obvious mistake, touched on by the original article: LD_PRELOAD is set to a string trailing with " /init", no doubt a copy+paste of the command line used to achieve the same execution during testing. The correct string would have omitted the " /init", and the mistake would have caused an error message like this to be printed for every executable launched until LD_PRELOAD is overridden:
ERROR: ld.so: object ‘/init’ from LD_PRELOAD cannot be preloaded (invalid ELF header): ignored.
Furthermore, this bootkit is incomplete, since it relies on chaining into components installed via another mechanism (e.g. /opt/injector.so in the initramfs). A true bootkit only relies on its own first stage to drop all subsequent stages. That’s the whole point of setting up a boot chain compromise like this. Otherwise you can defeat it by removing any of the stages, even if the bootkit stage is intact. As it stands, this bootkit isn’t really a bootkit, it’s just a module signing side-step that allows a traditional rootkit to be loaded on a system with Secure Boot enabled (and, since the Secure Boot is still working as intended, that results in a prompt on the first reboot asking the user to install the “bootkit”'s certificate into the UEFI trusted certificate store, since it is obviously not trusted by default). So it can’t even be installed without clear warning to the user that something is wrong.
Come on, @dangoodin. I expect better than this from Ars, and I expect a correction, because this is just inexcusable misinformation. The original article clearly mentions how to kill this “unkillable” bootkit, which tells me you didn’t even read the original article all the way.
A simple remedy tip to get rid of the bootkit is to move the legitimate /EFI/ubuntu/grubx64-real.efi file back to its original location, which is /EFI/ubuntu/grubx64.efi.
Update: article & headline have been updated.
This bootkit is not unkillable yet. If the diagram is correct, then it installs itself on the EFI partition and not the EFI Firmware.
Who would’ve thought replacing a BIOS with what’s essentially a micro-computer would open a can of worms…
Intel ME is a whole thing, too.
BIOS was always a micro computer… it’s just more standardized now.
And especially things like IPMI (which is essentially a company-sanctioned backdoor to any intel server) which has a full on webserver with an unknown number of threat vectors, things like this really fall flat for security.
Just because threats are found for UEFI (an open standard), it means nothing in grand scheme of things, just that it is more observed and more easily dissected for nefariousness.
I meant BIOS is way more limited in scope than UEFI and that’s a good thing.
Although since the limitation was most likely due to hardware of the day, i don’t know how would a modern BIOS look like.
Probably like UEFI
If you’re looking at Intel, you might be thinking IME/vPro
IPMI (such as iDRAC on Dell) runs off-processor on a different section of the motherboard typically and is installed on AMD servers as well.
Off topic but IPMI is such a handy feature. I’ve got an old x99 board with it, and man being able to remotely power cycle a frozen machine is missed. Even being able to change UEFI settings without having to drag out a monitor and keyboard.
I have five Dell servers in the rack, and another two Dells and three x9? (Atom C2758 8-core if memory serves) Supermicros on the shelf.
I think only one or two of the Dells came with iDRAC Enterprise and all the Supermicros had full licensing. It’s absolutely beautiful (once you get done fighting the software updates to purge the Java gremlins).
My three R730s were upgraded to Enterprise as soon as I had budget and a spare line item to do so. Power on/off is great and console+ISO is peak. I love this.
Unkillable? Bro have you even tried kill -9?
Permission denied. Use sudo