The researchers are keen to note things about this, but also likely want to avoid giving attackers "more ideas", which I feel limits the discussion. Plus, I highly doubt these attackers don't know everything we should be discussing.
This is obviously a low hanging fruit and first PoC implementation. The fact that secure boot can "mitigate" some of this attack right now is mostly due to the attacker being lazy or deploying an unfinished product. The researchers describe this as "unless they install the attackers certificate", which is a nice way of saying that the attacker has not spent much time fishing through DKMS and abusing the keys used for this purpose.
There are a lot of systems that are affected by this type of attack because for various purposes they have to sign their own modules. The most common example of this (until extremely recently, sort of) is Nvidia.
UEFI itself is way too complex, has way too much surface (I'm surprised this didn't abuse some poorly written SMI handler), and provides too little value to exist. Secure boot then goes on to treat that place as a root of trust, which is security architecture mistake, but works ok in this case. This all could be a lot better.
What makes you think that? Secure Boot prevents this rootkit from running and is the recommended mitigation:
> Bootkitty is signed by a self-signed certificate, thus is not capable of running on systems with UEFI Secure Boot enabled unless the attackers certificates have been installed.
> To keep your Linux systems safe from such threats, make sure that UEFI Secure Boot is enabled
In fairness, the blog post confusingly says this in the next bullet point:
> Bootkitty is designed to boot the Linux kernel seamlessly, whether UEFI Secure Boot is enabled or not, as it patches, in memory, the necessary functions responsible for integrity verification before GRUB is executed.
However, this would still require Rootkitty to have gained execution already, which it wouldn't be able to if Secure Boot was enabled and the malicious actor's certificates weren't installed.
Nothing. This is just a proof of concept that is ridiculously easy to detect. If your attackers can drop files in your /boot or /boot/efi directory, I think you have much worse things to worry about than this.
In fact, this bootkit would be about the least thing I would worry about. Because by the time an attack can write to /boot, they can also write to /etc/init.d . And the later is not protected by "secure boot".
The researchers are keen to note things about this, but also likely want to avoid giving attackers "more ideas", which I feel limits the discussion. Plus, I highly doubt these attackers don't know everything we should be discussing.
This is obviously a low hanging fruit and first PoC implementation. The fact that secure boot can "mitigate" some of this attack right now is mostly due to the attacker being lazy or deploying an unfinished product. The researchers describe this as "unless they install the attackers certificate", which is a nice way of saying that the attacker has not spent much time fishing through DKMS and abusing the keys used for this purpose.
There are a lot of systems that are affected by this type of attack because for various purposes they have to sign their own modules. The most common example of this (until extremely recently, sort of) is Nvidia.
I found this a rather interesting read, nice.
I cannot help but think the move to UEFI and Secure Boot made things less secure :(
UEFI itself is way too complex, has way too much surface (I'm surprised this didn't abuse some poorly written SMI handler), and provides too little value to exist. Secure boot then goes on to treat that place as a root of trust, which is security architecture mistake, but works ok in this case. This all could be a lot better.
The article says that Bootkitty does not work if Secure Boot is enabled. How do you figure Secure Boot made things less secure?
Gonna assume it's because you have to disable it to run your operating system of choice, unless you beg Microsoft to let you.
So that would be undesirable if true, but how would it be less secure than not having secure boot?
Of course, most/all SB BIOs enable setting your own platform key.
"Secure boot" is not actually meant to improve security.
It exists as a moat to make it harder to install Linux on your (Microsoft) PC.
does it also help keep drm keys safe? that's how it works on Android, they even delete the 4k keys if you root your phone.
What makes you think that? Secure Boot prevents this rootkit from running and is the recommended mitigation:
> Bootkitty is signed by a self-signed certificate, thus is not capable of running on systems with UEFI Secure Boot enabled unless the attackers certificates have been installed.
> To keep your Linux systems safe from such threats, make sure that UEFI Secure Boot is enabled
In fairness, the blog post confusingly says this in the next bullet point:
> Bootkitty is designed to boot the Linux kernel seamlessly, whether UEFI Secure Boot is enabled or not, as it patches, in memory, the necessary functions responsible for integrity verification before GRUB is executed.
However, this would still require Rootkitty to have gained execution already, which it wouldn't be able to if Secure Boot was enabled and the malicious actor's certificates weren't installed.
It's more secure than not having Secure Boot.
And significantly more complicated to setup and maintain in my limited experience :|
I guess we need to go to back to socketed eeprom chips.
Or just in general machines that are wholly controlled by the owner.
Previously: https://news.ycombinator.com/item?id=42260346
FYI Related articles:
https://news.ycombinator.com/item?id=42262525
https://news.ycombinator.com/item?id=42264655
I think they put the Y in the wrong place; should have called it bootykit!
What does the discovery of the Bootkitty UEFI bootkit for Linux systems suggest about the evolving landscape of cybersecurity threats?
It means "just trust us" is not and never was secure.
Trustworthy people don't ask you to trust them.
Nothing. This is just a proof of concept that is ridiculously easy to detect. If your attackers can drop files in your /boot or /boot/efi directory, I think you have much worse things to worry about than this.
In fact, this bootkit would be about the least thing I would worry about. Because by the time an attack can write to /boot, they can also write to /etc/init.d . And the later is not protected by "secure boot".