Found in the wild: The world’s first unkillable UEFI bootkit for Linux (arstechnica.com)
from purrtastic@lemmy.nz to technology@lemmy.world on 27 Nov 22:33
https://lemmy.nz/post/16774917

“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.”

#technology

threaded - newest

Illecors@lemmy.cafe on 27 Nov 23:01 next collapse

The Bootkitty sample ESET found is unable to override a defense, known as UEFI Secure Boot, that uses cryptographic signatures to ensure that each piece of software loaded during startup is trusted by a computer’s manufacturer.

AKA not that big of a deal, yet. An article from another post about this also mentions GRUB explicitly as a requirement as well as PoC using self signed keys, which renders it sort of impossible to abuse.

UKI + your own keys + secure boot is still not broken.

fuckwit_mcbumcrumble@lemmy.dbzer0.com on 27 Nov 23:16 next collapse

Unfortunately a lot of people in the Linux world still hate secure boot because they associate it with locking your PC to only running windows. Never mind the fact that basically every big Linux distro plays nicely with secure boot these days, and has for a while now.

Illecors@lemmy.cafe on 27 Nov 23:19 next collapse

Yea, I guess that initial total lack of understanding and big headlines has left a long-lasting scar. Admittedly, secure boot could be used to lock a machine down if the ability to turn it off and/or manage the keys yourself was removed.

We’ll get there, eventually :)

Shdwdrgn@mander.xyz on 27 Nov 23:26 next collapse

I associate it with the fight I’ve had every single time I tried to use it. It’s never been a smooth process on any server I attempted to use it on. Usually I either run into problems with a system not wanting to properly boot the memory stick even with a full UEFI image flashed to it, or if I do get that to work I go through the whole installation process only to find the system unbootable for whatever reason. Eventually I just give up and do a standard installation because why should I have to work this hard to put an OS on a machine?

9tr6gyp3@lemmy.world on 27 Nov 23:34 next collapse

Check out sbctl

Shdwdrgn@mander.xyz on 28 Nov 00:13 collapse

Shouldn’t this all be handled automatically by the Debian installer though? It seems weird that I would ever have to run other tools just to install a brand new system.

9tr6gyp3@lemmy.world on 28 Nov 16:26 collapse

Oh yeah Debian has their own documentation for SecureBoot. If thats not working though, check out sbctl.

charade_you_are@sh.itjust.works on 27 Nov 23:35 next collapse

I actually had a system that wouldn’t initiate the video card because of secure boot and many other problems with over the years that I repaired them for a living. Left a very bad taste in my mouth but if it’s actually improving I’ll it again.

Illecors@lemmy.cafe on 27 Nov 23:54 collapse

It is a system one has to understand fully, i.e. not like ssh, where you can understand connecting to a remote host without bothering about key pairs, x11 forwading, etc.

I was lucky enough to have figured out Gentoo enough where plugging in secure boot was just extending my own system update script. Admittedly, I don’t know how much other distros fight back.

Shdwdrgn@mander.xyz on 28 Nov 00:10 collapse

I’m on Debian, they’ve been providing UEFI images for a number of years so everything should “just work”. In fact I have one server where things did just work and that’s the only system using UEFI. Two other servers of the same model and BIOS version completely failed after numerous attempts so I finally said screw it and just did a normal install.

Illecors@lemmy.cafe on 28 Nov 11:28 collapse

Do you know how that works? Is it something like Ubuntu where Canonical uses some sort of chain from Microsoft or do you have to embed the cert they provide into UEFI yourself?

Shdwdrgn@mander.xyz on 28 Nov 18:12 collapse

Sorry, I really haven’t a clue. I just know once in awhile it does work, but usually it fails for me.

TheFogan@programming.dev on 27 Nov 23:56 next collapse

Never mind the fact that basically every big Linux distro plays nicely with secure boot these days, and has for a while now.

In my experience nicely is still pretty relative. It still seems to be the most common area things go wrong on my installs and place I have the hardest time working around…

and the bigger part, it’s a solution to a problem that I’ve never seen happen in the wild, and really can’t fathom happening on linux that doesn’t involve a very dumb user running software from an unknown source as root.

mlg@lemmy.world on 28 Nov 01:18 next collapse

The Fedora doc on this is a bit old but it’s still mostly the same:

Secure boot activates a lock-down mode in the Linux kernel which disables various features kernel functionality:

  • Loading kernel modules that are not signed by a trusted key.
  • Using kexec to load an unsigned kernel image.
  • Hibernation and resume from hibernation.
  • User-space access to physical memory and I/O ports.
  • Module parameters that allow setting memory and I/O port addresses.
  • Writing to MSRs through /dev/cpu/*/msr.
  • Use of custom ACPI methods and tables.

The implementation of secure boot is still questionable to this day, but it is understandable that it doesn’t always play nice with Linux. I do believe you can use hibernate now as long as you have an encrypted swap (LUKS).

I can definitely see the pain if you happen to be a kernel dev or use linux on any SBC with IO ports you want to mess with in userspace and not make en entire overkill kernel module for.

mox@lemmy.sdf.org on 28 Nov 04:56 collapse

because they associate it with locking your PC to only running windows.

They’re not exactly wrong. BIOS/UEFI bugs that make it a royal pain to use secure boot with anything but Windows are pretty common.

ftbd@feddit.org on 28 Nov 11:04 collapse

And many mainboards also suck in this regard. On mine, I can set secure boot mode to either ‘Windows OS’ (which means secure boot on) or ‘Other OS’ (which means secure boot is off). Took me a couple hours to figure that out

Kazumara@discuss.tchncs.de on 28 Nov 17:37 collapse

Can confirm. I’ve seen this on multiple boards. I think this was Asus nomenclature.

chevy9294@monero.town on 28 Nov 05:31 next collapse

Well… if you have your own keys (like I do) you have to store them somewhere. That somewhere is probably somewhere on a computer where they are used so you can update the kernel. If you have private keys, you can probably bypass secure boot.

Is there a way to have private keys stored on a nitrokey that has to be plugged in for every kernel update?

Illecors@lemmy.cafe on 28 Nov 08:58 collapse

Yes, failing to safeguard keys is fatal, but that applies to everything. But if fs you’re storing keys on is behind luks and they’re readable by root only - you’re as safe enough. There’re also LSMs like selinux that can increase the complexity of attack.

I don’t know about nitrokey specifically, but TPM is an option (not good enough, imo) and a simple luks encrypted usb. You could get some convenience by storing the key to unlock it somewhere on the encrypted root.

In general - you cannot stop a targeted attack no matter what, but staying safe from all the automated ones is doable.

chevy9294@monero.town on 28 Nov 12:54 collapse

They are stored behind luks and I think they are readable only by root. But bootkit can probably only infect UEFI from Linux that is running on that machine. And to interact to UEFI you probably have to be root, right?

I’ll look into more options, either store keys on a seperate luks usb key or on a hardware securety key like Nitrokey. For sbctl there is already a roadmap feature for hardware security keys, I hope this comes soon :)

wewbull@feddit.uk on 28 Nov 13:15 next collapse

This sounds like a good thing. I don’t care if the manufacturer of my equipment trusts the software. I care if I trust it.

Illecors@lemmy.cafe on 28 Nov 14:32 collapse

It is a good thing!

CriticalMiss@lemmy.world on 28 Nov 17:21 collapse

How many distros support secure boot out of the box? IIRC it’s only Ubuntu and RHEL. The rest require hacking some shit together with self signed keys.

Illecors@lemmy.cafe on 28 Nov 21:54 collapse

Don’t know, been rolling with Gentoo for some time now.

I wouldn’t trust “out of the box” support anyway as that would imply trusting microsoft keys.

CriticalMiss@lemmy.world on 29 Nov 03:17 next collapse

I checked my store and there are Canonical keys there, but I don’t think that’s on every computer.

raldone01@lemmy.world on 29 Nov 09:59 collapse

It is so annoying that one can’t ditch m$ keys and still boot windows. Sure you can sign the windows bootloader with your own keys. However it checks its own signature and just refuses to boot.

If anyone has a solution let me know.

progandy@feddit.org on 28 Nov 06:32 next collapse

This bootkit is not unkillable yet. If the diagram is correct, then it installs itself on the EFI partition and not the EFI Firmware.

0x0@programming.dev on 28 Nov 09:26 next collapse

Who would’ve thought replacing a BIOS with what’s essentially a micro-computer would open a can of worms…

Eximius@lemmy.world on 28 Nov 10:12 next collapse

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.

0x0@programming.dev on 28 Nov 16:19 next collapse

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.

thedeadwalking4242@lemmy.world on 29 Nov 04:23 collapse

Probably like UEFI

computergeek125@lemmy.world on 29 Nov 11:16 collapse

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.

dai@lemmy.world on 29 Nov 13:21 collapse

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.

computergeek125@lemmy.world on 30 Nov 11:57 collapse

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.

Randelung@lemmy.world on 29 Nov 10:15 collapse

Intel ME is a whole thing, too.

nyan@lemmy.cafe on 28 Nov 15:19 next collapse

Attacks only machines running specific Ubuntu kernels and using specific boot methods. Plus no actual payload. This doesn’t yet represent a real risk.

Where we’ll be in ten years’ time is unknowable, however. I think the Ars commentors who suggested going back to forcing jumper cap swaps or other hardware-mediated access requirements before overwriting the mobo’s boot firmware might be on the right track, even if it’s inconvenient for large corporate deployments. It’s normal for security and convenience to pull in opposite directions, and sometimes you just have to grin and bear it.

badbytes@lemmy.world on 29 Nov 03:29 next collapse

Unkillable? Bro have you even tried kill -9?

Wildone@sh.itjust.works on 29 Nov 05:00 collapse

Permission denied. Use sudo

qaz@lemmy.world on 29 Nov 10:13 collapse

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