Support us on Patreon
PayPalUsers of the popular bootloader may want to update their systems in order to mitigate the danger of this new exploit.
It’s been revealed that a series of bugs in GRUB2 compromises the chain of trust in a Secure Boot-enabled system. You can read about the full scope of the exploit here but the short of it is that arbitrary code can be executed by an attacker on virtually any system running GRUB2 and using Secure Boot. The attack allows modification of GRUB2’s configuration file and allows for privilege escalation which could potentially mean that intrusions can go undetected by booted operating systems.
Now, most of the risk comes from an attacker already having some level of privileges but this is still something that should give system administrators some pause. And while Windows systems are theoretically vulnerable as well, it’s far likelier that systems affected in the wild will be running Linux.
Researchers from Eclypsium were responsible for identifying this vulnerability and have responsibly disclosed the bug to maintainers and the wider ecosystem. Expect package updates in your distro sometime soon. Even then, updates aren’t a complete solution as the keys that Secure Boot rely upon also have to be updated and older ones blacklisted. The Debian project have a good overview of what should be done and I expect that other distributions will follow suit with their own advice on how to deal with this exploit.
GRUB2’s code has been audited since the initial disclosure and a series of other bugs have also been found in the last few weeks. While many users will ultimately be unaffected by this exploit it’s still a good reminder to keep your system up-to-date and keep an eye out for security advisories.
Article taken from GamingOnLinux.com.
Quoting: MnolegI'm surprised Debian stable is not using LILO as the default boot loader. Time to go back to Slackware.I've been using Syslinux* ever since continuing with legacy GRUB became awkward. I'm not saying it's the problem here, but GRUB 2's relative complexity always struck me as trouble waiting to happen.
*Which doesn't support Secure Boot at all. Not a problem for me, but it's obviously not a solution for everyone.
soulsource Jul 30, 2020
Quoting: bekoQuoting: scaineI think the irony is that it's meant to be "secure". Also, it was touted by MS for consumer laptops for "security" reasons, but in reality, putting the marketing BS aside, it just made Linux harder to install. This further solidified (as if that was needed) their monopoly on consumer O/S hardware.Ah… nope. That's BS. Sorry :) There is more to UEFI.
I can agree on that not everybody needs this.
The complaint was not about UEFI in general, but about the Secure Boot feature. The idea behind Secure Boot is not stupid, but that Microsoft is the only trusted issuer for keys is at least questionable from a market perspective.
(I am well aware that all UEFI implementations should allow custom trusted keys to be added, but let's be honest: How many mainboards ship with firmware that really exposes this, and how many users even know about that feature?)
Quoting: soulsourceThe complaint was not about UEFI in general, but about the Secure Boot feature. The idea behind Secure Boot is not stupid, but that Microsoft is the only trusted issuer for keys is at least questionable from a market perspective.Ok, got it :D
(I am well aware that all UEFI implementations should allow custom trusted keys to be added, but let's be honest: How many mainboards ship with firmware that really exposes this, and how many users even know about that feature?)
It's a miracle what a bunch of actual sentences can do.
I mean it's not like people _have_ to use Twitter style comments everywhere
After digging a bit, it will basically affect every Secure Boot system whether it uses GRUB2 or not. That is because all the trusted binaries and signatures will need to be invalidated. This doesn't make Secure Boot useless without repair, but there are a _lot_ of signed binaries that will need to be invalidated through their very poorly tested and vetted Revocation system.
Canonical appears to one of the least affected by this because their Secure Boot keys are run through an intermediary which they maintain and control. On one hand it minimizes the impact on users. On the other, a central authority gets to control and decide with no apparent community management or influence.
This issue is really caused by Microsoft controlling the CA that issues certs. Basically, signed bootloaders or shims must go through Microsoft. Another thread could be dedicated to why that is bad, but the point is that it is a significant cause and it still is. Nothing is changing in how this system works and it's flawed by implementation, not design. I don't really want Canonical, IBM, Oracle, Google, or anyone else to be a monolithic gatekeeper like this either.
If GRUB2 is loading the Windows Bootloader then Windows is directly vulnerable according to an article I read on CSO. It requires admin privileges on the Linux desktop and the user would need to allow code to modify grub and the windows bootloader. I'm not sure how realistically plausible it is to pull off. I don't dual boot either, but it's worth a further thought if you do.
My distro is Fedora. Fedora doesn't work with secure boot at all, out of the box at least. I think that's one of its weaknesses. It's also one area that feels most out of community reach to change. Both are a little frustrating to me.
Oh and the name doesn't mean anything but coincidentally could be pronounced as "Buttery" which suits me just fine.
See more from me