Sooo Ars, after correcting the original deeply flawed, pure clickbait article, has now doubled down with new info about how "Bootkitty" is actually used.
TL;DR: I was right about Bootkitty only being useful at all for UEFI Secure Boot systems. Turns out there's a separate component that exploits LogoFAIL, a year-old UEFI vulnerability discovered by researchers, to enroll Bootkitty's key into UEFI Secure Boot, which then bypasses the need for user consent for the new bootloader.
So, to recap:
There is no new vulnerability here. This is not a zero-day.Everything in this proof-of-concept attack is just putting things we already knew were possible together.Bootkitty is still just PoC level and useless on real production systems, since it still works only on a single Ubuntu kernel.Bootkitty is still not a real bootkit, just a component that's part of enabling the Secure Boot bypass, and trivial to remove and detect.This whole thing is still not persistent in any way in firmware, and trivial to remove. The LogoFAIL exploit is also stored on disk, not anywhere in firmware.This is not a remote exploit, or a local user exploit. You need root to install it, there is no extra OS-level exploit chain anywhere to be seen.The only news here is that someone decided to use LogoFAIL, which again was discovered a year ago, to create the capability of installing a traditional, old school kernel rootkit on UEFI Secure Boot systems without user consent on reboot. Which, again, is obviously possible when you have something like LogoFAIL. And you still need root access to install any of this.
To reiterate, this only matters if your threat model is an attacker might get root on my system, but they won't be able to install a kernel-level rootkit because I use Secure Boot, oh and also I didn't bother to patch LogoFAIL. Note that under this model an attacker can still install user-level rootkits anyway, so it's... certainly an interesting model. Also note that under this model an attacker can also just install any old known-vulnerable-to-something distro kernel (there is no revocation for those) and then exploit it to add the rootkit on every boot, achieving the same result of a module rootkit on a Secure Boot system without any of the LogoFAIL or Bootkitty nonsense. You could even just kexec into a backdoored newer kernel that way.
So, cute and interesting, yes. Still a PoC and a nothingburger for the security world. If you rely on UEFI Secure Boot's guarantees and you haven't patched LogoFAIL one year later, that's on you.
And if you take the Secure Boot stuff seriously you should probably get an Apple Silicon Mac anyway, because UEFI Secure Boot is Swiss cheese with a massive attack surface and stuff like LogoFAIL is bound to keep happening.
Edit: Aaaand it indeed was a student project.
https://social.treehouse.systems/@marcan/113570468222696147
https://social.treehouse.systems/@marcan/113560945800582652
https://en.wikipedia.org/wiki/LogoFAIL
https://social.treehouse.systems/@marcan/113585459997645726
No replies.
────