2024-11-28 ┃ edited ┃ RE: marcan
@dangoodin Since this is getting some traction and I expect questions about the "Secure Boot" part of the whole story, here's a TL;DR:
Secure Boot means one of three things:
Booting only code signed by the manufactuer or sole "blessed" providerBooting only code signed by "trusted" providersBooting code authorized by the end user (self-enrollment)1 is what you get on things like iDevices, which only boot code signed by Apple, and what people feared UEFI secure boot would be (Windows only). 2 is what UEFI secure boot actually is: the system will only boot stuff signed by people blessed by Microsoft (but supposedly they'll bless anyone). 3 is what UEFI secure boot becomes by using shim, which is a signed (Microsoft-blessed) tool shipped by Linux distros which, among other things, allows you to (via MokManager) enroll your own key so you can boot your own signed bootloader/kernel. (3 is also what you get on Apple Silicon Macs, directly, without the silly step of having to get some industry-standard shim signed by Apple as a workaround, but I digress)
Shim is how it is possible to install your own kernel/GRUB/bootloader on a system with Secure Boot enabled, without having to ask Microsoft for permission directly. You make your own keys, then on first boot it asks you whether the keys should be trusted, similar to how SSH trust-on-first-use works. After that, the keys are considered trusted for your own personal machine.
The bootkit is just the same as compiling GRUB/a kernel/etc on your own. After it gets installed, on reboot, the user will be prompted to add the bootkit's key, since it is not trusted. Once you explictly choose to trust the bootkit, of course then it can do anything it wants. And what it does is just patch the Ubuntu kernel to allow unsigned modules to load.
The same result could have been achieved without a bootkit at all, just by installing a custom signed GRUB and rootkitted kernel. The bootkit is just, in theory, a more convenient way to do this, since it can work together with distro-packaged kernels and binaries without having to ship backdoored versions of everything. In practice, since it's hardcoded for a single Ubuntu kernel version, it's almost useless, and not much different than no bootkit at all. Hence, proof-of-concept, nothing more.
The article also claims that the bootkit cannot bypass UEFI Secure Boot. While that is true in a literal sense, it's also, ironically, useless on systems without UEFI Secure Boot, since it is incomplete and not a true bootkit. On non-SB systems, what it does can be achieved just by editing /etc/default/grub (or a number of other ways). Its sole purpose seems to be to plug into a Secure Boot system and make a rootkit work with it, which it accomplishes without bypassing anything by requiring the user to approve installation just like a custom kernel would.
In other words, it's best described not as a true bootkit, but as a Secure Boot enabler shim for a typical, boring old rootkit. It does nothing else of value, and what it does is limited to a single vendor kernel and so clearly PoC-level.
If I ever teach a platform security course, I might just put "write a bootloader shim to make an off-the-shelf Linux rootkit work with UEFI Secure Boot enabled" on my homework list ;)
https://social.treehouse.systems/@marcan/113561803290693406
No replies.
────
────