PSA: Bad GRUB security patch
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. |
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. |
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 |
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. |
@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. |
Quote:
Quote:
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. Quote:
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. |
Quote:
|
Quote:
Quote:
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. |
Quote:
|
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.
Quote:
|
Quote:
EFI was just another Microsoft "innovation" waiting to be exploited. |
All times are GMT -5. The time now is 10:52 PM. |