Whenever a new security issue gets announced one of the first questions we all ask ourselves are: 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.
if my understanding is correct IF you use secure boot on ANY proprietary/closed motherboard (laptop/desktop/server/etc.?) you will only get that on a UEFI BIOS (but you can choose to have secure boot disabled in the BIOS settings before you init the kernel) so you can ONLY have a m$OS installed on the SAME storage device …
If Secure Boot is enabled, you can only execute a boot loader that has been signed by Microsoft. There are major Linux distributions like RedHat and Ubuntu that have gotten their boot loader GRUB2 shim signed by Microsoft so they can be booted when UEFI Secure Boot is enabled. Other distributions like PureOS haven’t, and can’t.
I’m confuses because what I’ve read appears to be targeting an audience that uses secure boot. Is just disabling it enough? Or is this a vulnerability that just defeats secure boot?
This vulnerability allows someone to bypass Secure Boot protections if you have them enabled. If you don’t have them enabled (and don’t use an alternative like PureBoot for boot security instead) then an attacker could have always modified your grub binaries directly to do malicious things without your knowing, even before this vulnerability was discovered.
While someone is patching GRUB2 to avoid this particular buffer overflow, perhaps they could enable Data Execution Prevention (which by now is an old technique to make buffer overflows more difficult to exploit).
I still get the impression, that one can trigger arbitrary chain loader via grub config file, since that config is not protected by Secure Boot. No need to exploit buffer overflows.
Kind of makes the whole Secure Boot thingy useless anyway.
Matthew Garrett has also demonstrated in past conference talks that since grub.cfg is not factored into Secure Boot, one could also simply append kernel arguments to disable security features within the kernel at boot time.
for those of you that buy RETAIL off the shelf proprietary motherboards you should be aware that SECURE-BOOT is DISABLED in the UEFI/BIOS settings out-of-the-box (you have to ENABLE it in most cases if you didn’t know this already) … i could care less about this as i clean-install my GNU/Linux distros on bare-metal quite often …
In my experience it really depends. About two years ago we were evaluating some low-cost hardware to see how it would run PureOS internally. It had a stripped down UEFI with an incredibly limited set of options and it turned out that because of that, they had gone ahead and enabled Secure Boot by default with no way to disable it. This meant that we couldn’t install either PureOS or Debian on this machine to try it out!
Like with so many things, “security” is the explanation and marketing term, but the actual reason comes down to control.
Hardware vendors desperately want to “secure” the boot process on laptops like they largely have on phones, and by “secure” they mean “control what software is allowed to run.” There are great advances, particularly with Apple hardware, in this regard. The cover story is always about preventing hackers from running exploits, but the real reason is preventing customers from jailbreaking devices and running their own software. With each advance, jailbreaking becomes more and more difficult.
it’s entirely possible that to the people DICTATING these measures hackers and customers have ALWAYS been synonymous … if you think about it from a human point of view they are the SAME !!!
