Description of problem:
From https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/

"Developers in Debian and elsewhere in the Linux community have recently become aware of a severe problem in the GRUB2 bootloader that allows a bad actor to completely circumvent UEFI Secure Boot. The full details of the problem are described in Debian Security Advisory 4735. The aim of this document is to explain the consequences of this security vulnerability, and what steps have been taken to address it. 

Multiple GRUB2 bugs found

Unfortunately, a serious bug has been found in the GRUB2 bootloader code which reads and parses its configuration (grub.cfg). This bug breaks the chain of trust; by exploiting this bug, it is possible to break out of the secured environment and load non-signed programs during early boot. This vulnerability was discovered by researchers at Eclypsium and given the name BootHole.

Instead of just fixing that one bug, developers have been prompted to do an in-depth audit of GRUB2's source code. It would have been irresponsible to fix one major flaw without also looking for others! A team of engineers have worked together for several weeks to identify and repair a range of further issues. We have found a few places where internal memory allocations could overflow given unexpected inputs, several more places where integer overflow in math calculations could cause trouble, and a few places where memory might be used after freeing it. Fixes for all of these have been shared and tested across the community.

Again, see Debian Security Advisory 4735 for a full list of the issues found.
Linux bugs found too

While discussing the GRUB2 flaws, developers also spoke about cases where Linux might also allow Secure Boot bypass. Two bugs were identified there, both allowing root to replace ACPI tables on a locked-down system when this should not be permitted. Fixes have already been released for those issues.
Key revocations needed to fix the Secure Boot chain

Debian and other operating system providers will obviously be releasing fixed versions of GRUB2 and Linux. However, that cannot be a complete fix for the problems seen here. Malicious actors would still be able to use older vulnerable versions of each to be able to work around Secure Boot.

To stop that, the next step will be for Microsoft to blacklist those insecure binaries to stop them being run under SB. This is achieved using the DBX list, a feature of the UEFI Secure Boot design. All of the Linux distributions shipping with Microsoft-signed copies of shim have been asked to provide details of the binaries or keys involved to facilitate this process. The UEFI revocation list file will be updated to include that information. At some future point, systems will start to use that updated list and will refuse to run the vulnerable binaries under Secure Boot.

The exact timeline for that change being deployed is not yet clear. BIOS/UEFI vendors will include the new revocation list in new firmware builds for new hardware at some point. Microsoft may also issue updates to existing systems via Windows Update. Some Linux distributions may issue updates via their own security updates process. Debian does not yet do this, but we are looking into it for the future.

What are the effects of key revocation?

Most vendors are wary about automatically applying updates which revoke keys used for Secure Boot. Existing SB-enabled software installations may suddenly refuse to boot altogether, unless the user is careful to also install all the needed software updates as well. Dual-boot Windows/Linux systems may suddenly stop booting Linux. Old installation and live media will of course also fail to boot, potentially making it harder to recover systems.

There are two obvious ways to fix a non-booting system like this:

- Reboot into "rescue" mode using newer installation media, and apply the needed updates that way; or
- Temporarily disable Secure Boot to regain access to the system, apply updates then re-enable it.

These may both sound like simple options, but each could be very time-consuming for users with multiple systems. Also be aware that enabling or disabling Secure Boot needs direct machine access, by design. It is normally not possible to change that configuration outside of the computer's firmware setup. Remote server machines may need special care here for exactly this reason."