Do you use Grub2? you should update now, they found about 8 vulnerabilities

If you are using Grub2 as your bootloader on your computer let me tell you that you should update it now, as 8 vulnerabilities in this GRUB2 bootloader were recently disclosed, one of which is marked as critical.

The most dangerous of them is the one it finds cataloged with the code name BootHole (CVE-2020 to 10713). This detected vulnerability makes it possible to bypass the UEFI Secure boot mechanism and install malicious software without checking.

The peculiarity of this vulnerability is that, to fix it, it is not enough to update GRUB2, since an attacker can use boot media with an earlier vulnerable version certified by a digital signature. An attacker can compromise the verification process not only for Linux, but also for other operating systems, including Windows.

And the problem is that most Linux distributions use a small layer of shim for verified startup, which is digitally signed by Microsoft.

This layer verifies GRUB2 with its own certificate, allowing distribution developers not to certify every kernel and GRUB upgrade to Microsoft.

By changing the content of grub.cfg, the vulnerability allows your code to run at the post-successful verification stage of shim, but before the operating system loads, snapping into the chain of trust when Secure Boot is Active and gaining full control over the additional boot process, including booting another operating system, modifying the components of the operating system, and avoiding crash protection.

The vulnerability is caused by a buffer overflow that can be exploited to execute arbitrary code during the download process. The vulnerability manifests itself by scanning the contents of the grub.cfg configuration file, which is usually located on an ESP (EFI System Partition) partition and can be edited by an attacker with administrator rights, without violating the integrity of the signed shim and the GRUB2 executables.

By error in the configuration parser code, the fatal parsing error handler YY_FATAL_ERROR only showed a warning, but did not end the program. The danger of vulnerability is reduced by the need for privileged access to the system; however, the problem may be necessary for the implementation of hidden rootkits in the presence of physical access to the computer (if it is possible to boot from its media).

Of the other vulnerabilities that were found:

CVE-2020-14308: Buffer overflow due to size of memory area allocated in grub_malloc not verified.
CVE-2020-14309: integer overflow on grub_squash_read_symlink, which can cause data to be written outside of allocated buffer.
CVE-2020-14310: integer overflow in read_section_from_string, which can cause data to be written out of allocated buffer.
CVE-2020-14311: integer overflow on grub_ext2_read_link, which can cause data to be written outside of allocated buffer.
CVE-2020-15705 - Allows direct boot of unsigned cores in safe boot mode without a sandwiched intermediate layer.
CVE-2020-15706: access to an already freed memory area (use-after-free) when canceling a function at runtime.
CVE-2020-15707: integer overflow in initrd size handler.


Although not everything is lost, since to fix this problem, only an update of the list of revoked certificates (dbx, UEFI Revocation List) should be performed on the system, but in this case, the ability to use old installation with Linux.

Some hardware manufacturers have already included an updated list of revoked certificates in their firmware; On such systems, in UEFI Secure Boot mode, only updated builds of Linux distributions can be loaded.

To correct the vulnerability in the distributions, the installers, boot loaders, kernel packages, fwupd firmware and compatibility layer must also be updated, generating new digital signatures for them.

Users should update the installation images and other bootable media, and download the Certificate Revocation List (dbx) in the UEFI firmware. Until the update of dbx in UEFI, the system remains vulnerable regardless of the installation of updates in the operating system.

Finally, it is reported that patch package updates have been released for Debian, Ubuntu, RHEL and SUSE, and for GRUB2, a set of patches have been released.



So, what’s the procedure on EndeavourOS? Is it enough to update regularly or is some intervention needed?


Good question :slight_smile:

[2020-08-01T03:08:36+0200] [ALPM] upgraded grub (2:2.04-7 -> 2:2.04-8)

Remove your bios chip, fry in in microwave, as well as RAM and drives… :zipper_mouth_face:

(That’s my tinfoil talking) :rofl:

:scream_cat: IT’S TOO LATE!!! :scream:
Aliens and CIA are already in my BootHole… :blush:


Yeah, I’m using the same version of grub. I’m not dual booting.

~🐸 pacman -Q | grep grub
grub 2:2.04-8
grub-tools 1.4.3-1
grub2-theme-endeavouros 20190711-4

So, what now?


Then you will need something other than a hat :stuck_out_tongue_winking_eye:


Grub 2:2.04-8 is patched for the BootHole exploit (patched and released on July 31).


:rofl: I’ll never get over it!!
Best vulnerability naming ever! :joy:

Oh look, we’ve just released a special patch to fix your BootHole! :rofl:
Safety first!! :sweat_smile:


I had the grub update and on one of my computers it ruined my startup with triplicate entries. I tried fixing it and ended up reinstalling my new setup with BTRFSonLuks and rEFIind so i got a bit of both worlds.

Ces’t la vie!

Edit: Maybe i fell in a boothole! :rofl:


Here you go, official BootHole OST! :surfing_man: :guitar:

1 Like

My boots have been vulnerable for quite some time:



This is what I’m using:



You put that in your BootHole? :scream:


You don’t wanna know what kind of a hole I am dealing with here!!


uefi is the malware is was always intended to me… working as expected… nothing to see here… please move along

Oh! This greatly surprised me.

I’d expected i’d need to do something additional to my normal daily routine.


Hey, stop judging!


The issues are mostly addressed, on the other hand, the vulnerabilities were/are an issue when Secure boot is on and the hacker has root privileges. If that is the case, your system was already vulnerable, because of that.


Yeah all these vulnerabilities like the processor spewing out encrypted data through cache and all, are mostly only a concern if someone has physical access to your PC and is willing to go through all that trouble. If your PC is a desktop sitting in your home the whole thing is a non-issue.

Same with this grub2 vulnerability. I mean for someone to be able to exploit this they’d either need to have root privileges, or they’d need to have physical access to your PC.

There might be concern for people with laptops in case they get stolen. But encrypting the home partition should still keep your data safe.