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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
18 comments
Heh, while awesome I highly doubt that anyone here uses TC and has a Chain Of Trust implemented (or even uses the TPM chip in any way even if one could and it's usually just sitting there waiting for You 
)
Thanks for sharing tho. Totally my alley :)
)Thanks for sharing tho. Totally my alley :)
2 Likes, Who?
Arehandoro Jul 29, 2020
Oh, the irony: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot
1 Likes, Who?
ertuqueque Jul 29, 2020
I think this article is totally justified just because of the name of the vulnerability!
Keep 'em coming!
Keep 'em coming!
3 Likes, Who?
Quoting: ArehandoroOh, the irony: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-bootWhat's the irony?
Secure Boot is part of EFI. That is not Microsoft specific.
0 Likes
Quoting: bekoQuoting: ArehandoroOh, the irony: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-bootWhat's the irony?
Secure Boot is part of EFI. That is not Microsoft specific.
I 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.
16 Likes, Who?
I'm surprised Debian stable is not using LILO as the default boot loader. Time to go back to Slackware.
2 Likes, Who?
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.
0 Likes
The whole point of the "secure boot" aspect of UEFI is to prevent vulnerabilities from happening and yet, here we are. That's irony.
While there is certainly more to UEFI than just Secure Boot, MS absolutely touted this feature since, as I recall in the beginning, MS or MS partners were the only ones allowed to hold the keys. This effectively meant that any non-MS OS could not be installed on a motherboard with this feature enabled. Of course, that changed eventually but a lot of us still hold a great deal of resentment towards MS over the whole thing.
While there is certainly more to UEFI than just Secure Boot, MS absolutely touted this feature since, as I recall in the beginning, MS or MS partners were the only ones allowed to hold the keys. This effectively meant that any non-MS OS could not be installed on a motherboard with this feature enabled. Of course, that changed eventually but a lot of us still hold a great deal of resentment towards MS over the whole thing.
7 Likes, Who?
Using Refind here
0 Likes
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.
0 Likes
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?)
5 Likes, Who?
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
1 Likes, Who?
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.
0 Likes
Also do not forget that Microsoft's "gold key" is actually compromised, meaning the SecureBoot is basically useless now.
4 Likes, Who?
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.
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.
2 Likes, Who?
Patreon
PayPal
Oh and the name doesn't mean anything but coincidentally could be pronounced as "Buttery" which suits me just fine.
See more from me