Whenever a new security issue gets announced one of the first questions we all ask ourselves is: am I vulnerable? We have started to get questions from our customers after the announcement of a series of major security bugs in GRUB2 so I felt that it was appropriate to write up a quick post to explain why, even though we use GRUB2 in PureOS, that Purism hardware is unaffected by the vulnerability. In summary, it’s because we rely on our own PureBoot boot firmware, not UEFI Secure Boot, to secure the boot process.
To understand why this flaw does not affect Purism computers, it helps to understand why UEFI Secure Boot exists to begin with, and how it and the security exploit works. Attacks on the boot process are particularly nasty as they occur before the system’s kernel gets loaded. Attackers who have this ability can then compromise the kernel before it runs, allowing their attack to persist through reboots while also hiding from detection. UEFI Secure Boot is a technology that aims to protect against these kinds of attacks by signing boot loaders like GRUB2 with private keys controlled ultimately by Microsoft. UEFI Firmware on the computer contains the public certificate counterparts for those private keys. At boot time UEFI Secure Boot checks the signatures of the current GRUB2 executable and if they don’t match, it won’t allow the executable to run.
If you’d like to understand the GRUB2 vulnerability in more detail, security journalist Dan Goodin has a great write-up at Ars Technica. In summary, an attacker can trigger a buffer overflow in GRUB2 as it parses the grub.cfg configuration file (this file contains settings for the GRUB2 menu including which kernels to load and what kernel options to use). This buffer overflow allows the attacker to modify GRUB2 code in memory and execute malicious code of their choice, bypassing the protection UEFI Secure Boot normally would have to prevent such an attack.
Unfortunately, UEFI Secure Boot doesn’t extend its signature checks into configuration files like grub.cfg. This means you can change grub.cfg without triggering Secure Boot and the attack exploited that limitation to modify grub.cfg in a way that would then exploit the running GRUB2 binary after it had passed the signature check.
Further complicating the response to this vulnerability is the fact that it’s not enough to patch GRUB2. Because the vulnerable GRUB2 binaries have already been signed by Microsoft’s certificate, an attacker could simply replace a patched GRUB2 with the previous, vulnerable version. Patching against this vulnerability means updating your UEFI firmware (typically using reflashing tools and firmware provided by your vendor) so that it can add the vulnerable GRUB2 binary signatures to its overall list of revoked signatures.
Purism computers aren’t affected by this GRUB2 vulnerability in two main ways. First, we don’t use UEFI Secure Boot on our Librem laptops, Librem Mini, Librem Server or any other products. We do this for philosophical reasons as I explain in my post introducing PureBoot:
Unfortunately, most of the existing approaches to protect the boot process also conveniently (conveniently for the vendor, of course) remove your control over your own system. How? By using software signing keys that only let you run the boot software that the vendor approves on your hardware. Your only practical choices, under these systems, are either to run OSes that get approval from the vendor, or to disable boot security altogether. In Purism, we believe that you deserve security without sacrificing control or convenience: today we are happy to announce PureBoot, our collection of software and security measures designed for you to protect the boot process, while still holding all the keys.
So whether your Librem computer uses our default coreboot firmware or PureBoot, UEFI Secure Boot is not enabled or used.
Second, because of how PureBoot works, even if an attacker were to attempt this vulnerability on one of our systems, PureBoot would detect it. This is because in addition to detecting tampering in the boot firmware itself, PureBoot uses your own keys to look for changes in every file in the /boot directory. This includes not only your GRUB2 executables, but extends into every kernel you have installed, their corresponding initrd files and even includes your grub.cfg file. So if an attacker modifies your grub.cfg file, PureBoot will detect the attack the next time you boot.
Boot security is challenging but it’s also fundamental to the security of your whole system. Trust starts with the first code your CPU executes and until you can trust your boot firmware (UEFI, coreboot, or PureBoot) and your boot code (GRUB2) you can’t trust the integrity of the rest of the system. This is why we have invested so much effort into a solution like PureBoot so you can have a secure boot process where you hold the keys, and that doesn’t rely on Microsoft, Purism, or any other vendor for your security.