Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

Users 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.
Tags: Security, Misc
16 Likes
About the author -
author picture
History, sci-fi, technology, cooking, writing and playing games are things I enjoy very much. I'm always keen to try different genres of games and discover all the gems out there.

Oh and the name doesn't mean anything but coincidentally could be pronounced as "Buttery" which suits me just fine.
See more from me
The comments on this article are closed.
19 comments
Page: «2/2
  Go to:

Dunc Jul 30, 2020
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: beko
Quoting: 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?)
Koopacabras Jul 30, 2020
just received a grub-common update
beko Jul 30, 2020
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.
(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?)
Ok, got it :D

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
Nanobang Jul 30, 2020
View PC info
  • Supporter
Installing the fix now ... thanks for the heads up!
CFWhitman Jul 30, 2020
I have dealt with a number of computers that included UEFI before Secure Boot was implemented. Many of the business laptops lacked a lot of possible features, but they did allow the UEFI boot method. My old desktop motherboard from home (which I still use as a second desktop in the cellar) has quite a full-featured UEFI implementation, but it predates Secure Boot.
omer666 Jul 30, 2020
Also do not forget that Microsoft's "gold key" is actually compromised, meaning the SecureBoot is basically useless now.
randyl Jul 30, 2020
Great article BTRE. It got me to read the links and dig around for more info. This seems to be a lot bigger than it looks on the surface. Here are my thoughts.

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.
razing32 Jul 30, 2020
Well , I am on Arch with EFI
But...
Once i install my system i never reboot.....so.....
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.