Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Linux

The World's First Unkillable UEFI Bootkit For Linux (arstechnica.com) 29

An anonymous reader quotes a report from Ars Technica: Over the past decade, a new class of infections has threatened Windows users. By infecting the firmware that runs immediately before the operating system loads, these UEFI bootkits continue to run even when the hard drive is replaced or reformatted. Now the same type of chip-dwelling malware has been found in the wild for backdooring Linux machines. Researchers at security firm ESET said Wednesday that Bootkitty -- the name unknown threat actors gave to their Linux bootkit -- was uploaded to VirusTotal earlier this month. Compared to its Windows cousins, Bootkitty is still relatively rudimentary, containing imperfections in key under-the-hood functionality and lacking the means to infect all Linux distributions other than Ubuntu. That has led the company researchers to suspect the new bootkit is likely a proof-of-concept release. To date, ESET has found no evidence of actual infections in the wild.

Still, Bootkitty suggests threat actors may be actively developing a Linux version of the same sort of unkillable bootkit that previously was found only targeting Windows machines. "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." [...] As ESET notes, the discovery is nonetheless significant because it demonstrates someone -- most likely a malicious threat actor -- is pouring resources and considerable know-how into creating working UEFI bootkits for Linux. Currently, there are few simple ways for people to check the integrity of the UEFI running on either Windows or Linux devices. The demand for these sorts of defenses will likely grow in the coming years.

The World's First Unkillable UEFI Bootkit For Linux

Comments Filter:
  • Eh, err... Nevermind
  • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday November 27, 2024 @06:33PM (#64976641) Homepage Journal

    Summary claims firmware is infected.

    Article claims GRUB and kernel are infected.

    • by evanh ( 627108 )

      Yeah, looking like they all make use of the UEFI formalised storage(partition) on the HDD/SSD. So the idea of it being in the firmware is plain wrong.

    • by bill_mcgonigle ( 4333 ) * on Wednesday November 27, 2024 @06:57PM (#64976665) Homepage Journal

      I would still prefer a 1989-style BIOS flash jumper, though.

      Please let me pay $10 more for a $0.04 jumper. I don't even care if it's dangerous by default to keep the support calls down.

      • >"I would still prefer a 1989-style BIOS flash jumper, though."

        THIS. I was going to say the same thing. Why can't we have some PHYSICAL barrier to messing with important stuff!?! Doesn't even have to be a jumper- how about holding the reset button why pressing power on?

      • by tlhIngan ( 30335 ) <slashdot&worf,net> on Wednesday November 27, 2024 @08:34PM (#64976765)

        I would still prefer a 1989-style BIOS flash jumper, though.

        Please let me pay $10 more for a $0.04 jumper. I don't even care if it's dangerous by default to keep the support calls down.

        That only worked because the BIOS chip was a ROM chip that had separate address, data and control lines. To write to them you needed to actually control the write enable line. The jumper made it such that it was not possible to write to the chip because it would physically disconnect the line.

        These days, the BIOS is within a LPC (low pin count) interface, which is a bidirectional interface. There is no write enable line you can control - if you did it on the interface, it would disable it from working. It's just a high speed serial interface used to talk to many low speed peripherals without consuming many pins. There is no way you can physically disconnect the ability to write to the chip because you need to write to it in order to read from it.

      • Yes. This. Or maybe a mode like modern PCs where you put the BIOS update on a USB flash drive, stick it in a slot, power the machine down, hold down a button on the back, so the motherboard processor (not the CPU) fetches the BIOS update and applies it, all offline. Something that takes direct user action.

        For company owned PCs, have it signed by whatever MDM is managing them.

        This should be a solved problem, as exactly the parent mentioned. People knew that rogue BIOS flashing was a thing decades ago, an

      • by dfghjk ( 711126 )

        Why take such lame half measures? Socketed EPROMs eliminate issues with flash updates altogether.

      • by MrKaos ( 858439 )

        I would still prefer a 1989-style BIOS flash jumper, though.

        or EPROMS. If only we knew now what we knew then.

  • Additionally, the inability to defeat Secure Boot limits infection opportunities to devices that (1) don’t enable the defense or (2) have already been compromised by the same attacker to install a self-signed cryptographic certificate.

    Why would you install a signed bootloader shim only to also disable the very purpose of having a signed bootloader shim? Isn't the point of the signed GRUB shim to enable UEFI secure boot? *facepalm*

  • by nukenerd ( 172703 ) on Wednesday November 27, 2024 @06:55PM (#64976661)
    This is the year of the Linux bootkit on the desktop.
  • "The Bootkitty sample ESET found is unable to override a defense, known as UEFI Secure Boot"

    So if an attacker gets root they can install anything into the EFI partition, and if secure boot is off, the computer will boot it? Whoop-de-doo... how is this anything new?

    • It's notable because it corrupts the bootloader and the kernel in-memory at a very early stage, while leaving no trace of a corrupted grub or kernel binary on disk.

      Currently, the malicious pre-grub patcher is stored on the ESP so it's as "simple" as using an external trusted host to scan the boot drive and erase it. The fact that it works on the kernel by just blinding overwriting certain offsets clearly says "this is a prototype." But if they can find a way to write it into the bios flash, that's Game O
  • Just out of curiosity, is it still possible to choose booting Windows using MBR instead of UEFI?
    • Windows 10? Yes. Windows 11? No. People should be migrating off of 10 to something else anyway.

      • That's interesting, because it was possible. I did it in a VM by accident by not turning enough stuff on and turning off too many checks. When I later wanted to turn all the features on I had to convert my "disk" to the newer format.

  • "Now the same type of chip-dwelling malware has been found in the wild for backdooring Linux machines."

    ...

    "To date, ESET has found no evidence of actual infections in the wild."

    These contradictions are in the same paragraph. Not just the same article. No one edits their chatbot's work at Ars, apparently.
  • Putting an extensible mini operating system in the system firmware to use as a glorified boot loader? Color me surprised that it hasn't been exploited more often.

    Seriously. the things that belong on my motherboard's Flash is simple. System board information, such as model number and layout. Default mappings of peripherals and slots on the bridge hierarchy. Some initialization for memory and bus training procedure. Trampolines for suspend and resume power states. Some boot loader code, like load some sectors

How many Unix hacks does it take to change a light bulb? Let's see, can you use a shell script for that or does it need a C program?

Working...