Friday, 31 July 2020

UEFI Secure Boot is in chaos!

As you may be aware, the agFM grub2 boot files which are added to the second FAT32 partition when you make an Easy2Boot v2 USB drive uses a Kaspersky shim to load the a1ive grub2 kernel.

Because the Kaspersky shim is signed, it means  that it can load the grub2 kernel which can then effectively disable Secure Boot!

This allows us to boot an insecure grub2 kernel and we can do pretty much anything we like to the system, including booting to non-secure OS's!

This loophole was reported to Microsoft last year (if not before!) and Microsoft tried to fix it using a Windows Update KB which was rolled out to all Windows 10 systems earlier this year. The 'hotfix' added an entry into the UEFI firmware dbx 'blacklist' of the BIOS. Thus the signed Kaspersky shim file was blacklisted by the UEFI BIOS.

Unfortunately, the KB hotfix caused problems with many systems because the same signed Kaspersky shim was used by some OEMs as standard - so these systems suddenly refused to Secure UEFI-boot after the Microsoft Update was applied!

So Microsoft quickly reversed the KB Kaspersky hotfix part in the next hotfix removed the blacklist dbx entry from the UEFI BIOS again. So - assuming you could get your system to non-secure boot by disabling Secure Boot in the BIOS, you could do a Windows Update and then re-enable Secure Boot again. Of course, your system would still be vulnerable though.

Since then it seems Microsoft, Linux developers and grub2 developers have actually bothered to look at and analyse the shims and grub2 code which they are getting signed and have found a large number of other vulnerabilities too!  To me this raises a number of questions about the Microsoft Secure Boot signing process:
  1. What did Microsoft actually do when they signed Secure Boot files - just accept a huge amount of $$$ and sign any old boot file without bothering to fully analyse it?
  2. Why does everyone insist that Open Source code is so desirable when there has been gaping security holes in grub2 for years?
A recent number of these vulnerabilities have now been fixed in grub2, but updating systems is not going to be easy! We cannot simply blacklist all current and older versions of grub2 by adding entries to the UEFI dbx blacklist. This would prevent any OS on older drives, backups, old install media, USB drives, PXE servers, etc. from Secure Booting because they would still contain the old, blacklisted, grub2 signed UEFI boot files. See the 'mitigation' section of this article for more details.

For the complete picture, read the whole article here.

Note also that very new linux/grub2 OS's (install ISOs and updates) may have these new 'fixes' added and it may prevent them from UEFI Secure booting and in some cases even non-Secure UEFI booting then fails!...

July 30 Important Update

Some of the Linux distribution updates appear to be leading to unsuccessful reboots. The developers and distribution maintainers are working to provide new updates. The maintainers are recommending to avoid installing updates for grub2, shim, and other bootloader-related applications until new packages are available. Some of the issues to watch are listed below:


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)