Pat and all Slackers using GRUB,

Wednesday a GRUB boot loader security flaw was announced around the web. Thursday many major distro maintainers hastily released a patch. Hastily releasing a patch was in poor judgment because exploiting the flaw requires access to a computer and admin privileges.

This patch is causing many systems to fail to boot. Rather than boot normally the computer drops to a GRUB rescue prompt.

I confirmed the failure on a Debian system.

Pat, please let the dust settle on this mess before pushing a patched GRUB package to 14.2 and Current.

Thanks!

I do not use GRUB2, but our esteemed Didier Spaier has already given a comprehensive post
The theres-a-hole-in-the-boot link is informative. The problems will not be in the patches, but rather from the endeavours to fix the breakage in the chain of trust.

1 members found this post helpful.

The Debian systems I tested do not use secure boot. The patches broke GRUB. All I am asking Pat is proceed in his usual cautious manner before pushing patches.

I use GRUB on Slackware systems as do other Slackers. If Pat wants to push proposed GRUB patches to the /testing branch I'll be happy to help test.

3 members found this post helpful.

yes, it seems other distributions already shoot themselves in their feet with these grub2 updates

https://bugzilla.redhat.com/show_bug.cgi?id=1861977
https://access.redhat.com/solutions/...a000002goqWAAQ
https://bugs.centos.org/view.php?id=17631

1 members found this post helpful.

I totally agree that this issue is being overblown. A company (with a name that I cannot dissociate mentally from eclampsia) has found a flaw that at this time can only be exploited with root privileges. With that level of access, attack on UEFI seems a low priority.
The fallout from this will be huge. The introduction of UEFI was driven by the Microsoft desire to protect the Windows 10 operating system. Microsoft leveraged the power it has over hardware manufacturers to introduce the required hardware changes. To avoid complaints of unfair competition, Microsoft needed to allow alternative operating systems to be run. The flaws in the adopted mechanism are now being exposed. There is now an impossible balance between the competing interests of administrators requiring secure systems as an immediate priority versus administrators requiring stable functional systems for hundreds/thousands of users.

3 members found this post helpful.

@upnort: to make use of the information you gave we need to know which is the "bad" patch.

If you use Debian stable aka Buster I assume that this patch is included in http://security.debian.org/debian-se....debian.tar.xz. However the 'series' file in the debin/patches directory mentions 170 patches (including CVE-2020-10713.patch), so it's hard to know which one is bad...

EDIT: looking at the Centos link provided by Matteo faulty patch could be in mokutil or shim, not grub itself. If this is correct Slackware users are not at risk at all

Anyway I don't think that Patrick will ever apply an untested patch, so we are safe.

It's apparently not affected, because Slackware does not patch the upstream grub sources with distribution specific stuff. Plus it doesn't even install grub by default.
According to this source, Gentoo is not affected either.

Exactly. There was no need to hastily push packages without testing.

I agree. On two Debian systems I tested both failed to boot. This is the Slackware forum but since you asked there were six related Debian packages released yesterday:

grub2-common_2.02+dfsg1-20+deb10u2_amd64.deb
grub-pc-bin_2.02+dfsg1-20+deb10u2_amd64.deb
grub-efi-amd64_2.02+dfsg1-20+deb10u2_amd64.deb
grub-efi-amd64-bin_2.02+dfsg1-20+deb10u2_amd64.deb
grub-common_2.02+dfsg1-20+deb10u2_amd64.deb
grub-efi-amd64-signed_1+2.02+dfsg1+20+deb10u2_amd64.deb

Both of the systems I tested are not using EFI or secure boot so those packages were not the cause.

I had to boot with a Live USB and chroot into the systems to restore the older package versions. I haven't yet found a long-term solution other than holding the packages.

I don't know if the buggy packages are distro specific or derived from the upstream GRUB sources. The hasty patched packages affect Red Hat/CentOS systems too.

This entire event was handled -- horribly.

My primary intent for this thread is to provide a simple warning to Pat and Slackers. I'm not interested in Yet Another Ten Page Debate About Nothing Forum Thread.

1 members found this post helpful.

This is about CVE 2020-15707, mentioned by Daniel Kiper as additional bug, not the main issue filed as CVE-2020-10713.

Sure thing, but from what I can tell; it's the distributions' patch which makes systems not boot properly, and not the original exploit.

You quote me to complain about these unrelated things I have no control over, assuming and/or implying I have had some part in it?
How is this my problem? Aren't there moderators here to address your concern?

I prefer GRUB also, and am not overly concerned about this exploit. It would be nice to have it patched, but a functioning boot process is a bit more important!

I have latest antiX (based on Debian Buster without systemd), the only module that is not installed is

grub-efi-amd64-signed_1+2.02+dfsg1+20+deb10u2_amd64.deb

system boots without issues after latest update.

Not your problem. I wasn't citing you or speaking to you. I was being generic because so many Slackware forum threads these days degenerate.

Not related to Slackware (hopefully), but at work on the Debian systems I support the solution is rather straightforward. After updating and before rebooting, run grub-install and update-grub.

I am not surprised if that is the case

Right now, I'm so glad I blew away the EFI partition system and went back to the "legacy BIOS" boot chain.

EFI was just another Microsoft "innovation" waiting to be exploited.