At these levels Linux doesn't need to include the functionality. This operates below the kernel and can include its own functionality without the Kernel ever seeing it present.

Where this code lives they can sit passively by until you've decrypted your hard drive (capturing your key in the process), patch the kernel with a rootkit, and start processes or drop files that will be invisible and inaccessible to even other kernel processes.

This isn't a vulnerability in Windows, or Linux. This is drinking from a polluted pool before they come into existence and poisoning the system.

You are describing some sort of firmware modification attack. That is not what this is. If the software stub is not actively downloaded by the OS then it can't run. This exploit is very specific to a bonehead thing Windows does. No other OS (e.g. Linux) would be vulnerable.

You're talking about an attack against the agent this is designed to download, or you don't understand what a UEFI attack is. This is an attack against the UEFI part, not the agent. This isn't firmware, but it is pre-bootloader. UEFI is the bootloader that loads your bootloader and is stored not on your hard drive.

If software at this level is malicious, it has equal privileges as your BIOS before any kernel gets loaded. It doesn't matter what the operating system is, it just has to be designed for it. It can return TPM approved checksums to your kernel and continue a secure boot as long as it knew what those checksums were before it modified them. Oh you use an external drive for your unencrypted boot partition? That can be modified as it is read off disk, before you're ever prompted for a disk passphrase, and it will report the correct checksum before it gets loaded.

This is a vicious level of access for malicious software, and it is OS agnostic as far as the attack goes. THIS instance is Windows only because that is what it was targeted at.

I am talking about the attack against the agent because that was the attack that josteink stated that Linux was not susceptible to.

> If Linux included functionality to have the firmware legitimately push applications

Does it need to? Is there anything stopping the firmware dropping, say, a systemd service on the disc?

That’s not legitimate. This is a documented api the firmware can use to get Windows to run a binary at boot.

Or a start up script on SysV Init systems.

Here are some easy ways to prevent UEFI from tampering with your drive:

Disable UEFI. https://github.com/corna/me_cleaner

Disable the ACPI hooks that register the kernel with UEFI. http://heim.ifi.uio.no/~knuto/kernel/4.14/admin-guide/kernel...

Use full disk encryption - unlike Microsoft Bitlocker which left backdoors for LoJack, linux vulnerabilities are publicized and you can update as soon as the patch appears on the internet.

Switch to a filesystem that the UEFI malware does not understand. Or move fields and magic numbers around in an existing filesystem to create a "custom" filesystem.

Or a combination of all of the above.