It's kinda ridiculous reading the comments in here.
This is a persistence stage exploit mechanism, meaning in order to install it, privilege escalation happened before that and it already got root rights.
The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
That is the conceptual issue that cannot be fixed, and also not with TPM or whatever obscurity mechanism in between.
Linux needs to be a rootless system, meaning that there needs to be a read only partition that root can never read. That would limit access to this kind of thing to physical access or the kernel ring at the very least. Technically, this was the intent of efivarfs, but look at where vendor firmware bugs got us with this.
> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
The majority of Linux machines out there are running vanilla, distribution-signed kernels. For most people, the only reason to build your own kernel (modules) is Nvidia.
> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
If, hypothetically, you were using a system without custom keys, e.g. with a third party kernel trusted via the Microsoft / Red Hat shim program, [1] wouldn't you be safe, so long as secure boot was enabled? The bootkit would not be able to sign itself with a trusted key since the private key would never exist on the system to begin with.
Obviously, I'm aware that this approach has other problems and has had vulnerabilities in the past.
You don't need to do your signing locally, it is possible to build your network around a build machine that does the signing for you. That being said, SecureBoot has always been security theater for anyone that isn't a major OS manufacturer or industry player. The fact is, as soon as cryptography comes into the picture the majority of the computing populace have already left the conversation.
If you roll your own keys, as MS happens to lose some. But as I replied to parent, storing them on a fido2 device or in a crypted file would alleviate the issue. If not, please educate me.
This is a persistence stage exploit mechanism, meaning in order to install it, privilege escalation happened before that and it already got root rights.
The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
That is the conceptual issue that cannot be fixed, and also not with TPM or whatever obscurity mechanism in between.
Linux needs to be a rootless system, meaning that there needs to be a read only partition that root can never read. That would limit access to this kind of thing to physical access or the kernel ring at the very least. Technically, this was the intent of efivarfs, but look at where vendor firmware bugs got us with this.