3 ms·

Does uefi secureboot help or not at all?

• blueflow 2y ago
  Not at all.
• pushupentry1219 2y ago
  I'm curious to understand why you would think that it would protect this at all?
• jeroenhd 2y ago
  The article describes a hooking library as a rootkit but I can't see any indication of this rootkit inserting itself into the boot process. Instead, it seems to LD_PRELOAD itself into processes at a later stage. Secure boot won't help here. In theory one could configure a system to only trust executables and DLLs signed by a trusted, external signatory (like a locally hosted package repository) but I don't know of any Linux distros that make it easy to set up something like that. You'd also need to invent something to sign scripts, because signing binaries is only a part of the problem (in theory you could set this up Powershell, I think? But I doubt many Linux systems will boot with PS in the place of /bin/sh). Once the kernel launches the init process, the rest secure boot verification chain essentially ends. It seems to me that prevention isn't hard by simply updating old software and perhaps running antivirus software on your servers.
  • jcalvinowens 2y ago
    I use a read-only squashfs rootfs on top of dm-verity to get a trusted userspace. The initramfs is a 50 line shell script which calls veritysetup with the known root hash, and is itself part of the signed boot image. Only /var is writable.
• johnfernow 2y ago
  I'm not sure, outside of my expertise, but I think it might not help. The attack takes place after boot, so maybe at best UEFI secureboot could prevent persistence of the malware, but I don't think it'd even achieve that, as the malware adds popular Linux utilities that were modified to serve as user land rootkits, and runs them by modifying the ~/.profile script. That script is ran when the user logs in (it starts the malware first, and then everything that's supposed to run on the server after), and I don't believe UEFI secureboot has any protections against ~/.profile script modifications or rootkits ran after boot.
• vaylian 2y ago
  See the mitigation section in the article: https://www.aquasec.com/blog/perfctl-a-stealthy-malware-targeting-millions-of-linux-servers/#section-7 https://www.aquasec.com/blog/perfctl-a-stealthy-malware-targ... UEFI won't help here. But keeping your system up to date and limiting the system to the necessary functionality will help you.
  • opengears 2y ago
    In the mitigation section there is written 'Deploy Runtime Protection: Use advanced anti-malware and behavioral detection tools that can detect rootkits, cryptominers, and fileless malware like perfctl.' -- which tools can we currently use to detect perfctl?
    • ykonstant 2y ago
      I hear Crowdstrike is king (≖ ͜ ≖)
      • doubled112 2y ago
        To be fair, a system that rebooted and won't come back up IS pretty secure.
        • AStonesThrow 2y ago
          No, because it's a denial of service. C-I-A triad: Confidentiality, Integrity, Availability. A dead system is confidential, and if that's your criterion, then fine, but legitimate users may require access to intact data and services.
          • doubled112 2y ago
            Sure, and availability in this sense is often forgotten, but I was only joking about Cloudstrike's ability to block malware. A dead machine is difficult to infect with malware. You'd have to go out of your way to do so.