BootHole vulnerability in Secure Boot affecting Linux and Windows

[Brink]

“BootHole” vulnerability in the GRUB2 bootloader opens up Windows and Linux devices using Secure Boot to attack. All operating systems using GRUB2 with Secure Boot must release new installers and bootloaders.

Join Eclypsium for a webinar “Managing The Hole In Secure Boot” on August 5th, where CEO Yuriy Bulygin and VP R&D John Loucaides will provide advice on mitigating this vulnerability.

Download the PDF >

INTRODUCTION

Eclypsium researchers have discovered a vulnerability — dubbed “BootHole” — in the GRUB2 bootloader utilized by most Linux systems that can be used to gain arbitrary code execution during the boot process, even when Secure Boot is enabled. Attackers exploiting this vulnerability can install persistent and stealthy bootkits or malicious bootloaders that could give them near-total control over the victim device.

The vulnerability affects systems using Secure Boot, even if they are not using GRUB2. Almost all signed versions of GRUB2 are vulnerable, meaning virtually every Linux distribution is affected. In addition, GRUB2 supports other operating systems, kernels and hypervisors such as Xen. The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. Thus the majority of laptops, desktops, servers and workstations are affected, as well as network appliances and other special purpose equipment used in industrial, healthcare, financial and other industries. This vulnerability makes these devices susceptible to attackers such as the threat actors recently discovered using malicious UEFI bootloaders.

Eclypsium has coordinated the responsible disclosure of this vulnerability with a variety of industry entities, including OS vendors, computer manufacturers, and CERTs. Mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack. This will likely be a long process and take considerable time for organizations to complete patching.

TABLE OF CONTENTS

• Background: Secure Boot, GRUB2, and CAs
  • Threats to the Boot Process
  • UEFI Secure Boot
  • Chains of Trust and GRUB2
  • Challenges of Secure Boot
• Breaking Secure Boot Through GRUB2
  • Vulnerability Analysis
  • Additional Vulnerabilities
  • Impact
• Mitigation
  • Recommendations
• Conclusions

Read more: https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

 

[Brink]

More: ADV200011 | Microsoft Guidance for Addressing Security Feature Bypass in GRUB | Security Advisory

 

[file3456]

Whelp, so much for the idea of the word "secure" in the phrase Secure Boot.

My PC clairvoyance (which is now the second time I used this word today LOL) told me that UEFI and the so-called Secure Boot crap was going to be vulnerable one day. I just knew it. Hence it is why I don't even use Secure Boot (pretty sure I don't) and UEFI (my motherboard gives me this option). I can't use it anyway and I made sure to turn it off since I use the now defunct Truecrypt for my FDE needs. Granted there are some vulnerabilities with Truecrypt, I have mitigations in place for those and I followed the audit and watched the hour long DEFCON presentation on its code audit which was weird because as the Truecrypt code was being audited was when the "hidden" Devs out right said it isn't secure, use Bitlocker instead which to me sounds just like a Lavabit situation. At any rate, when the code audit was completed, and from what I read, other then some sloppy code, there were no backdoors or other shenanigans. I have tried VeraCrypt in a Windows 10 installation in VMware Workstation Player and it does look nice and offers a lot more features and what not, but I'm just a little leary about using it until it too gets an audit which may never happen seen as how I have have read that porting Truecrypt may not be exactly legal. All that rot is at Steve Gibson's website.

Anyway, just another one in a I don't know how many CVEs that are posted on a day by day basis. Although this one could be a lot more broad and problematic depending on the "hoodie wearing haxxers" and what they do with it. I'm not too concerned about it for my computers at present, but I am with my host's servers and the use of CentOS. From the server standpoint this could be a very big issue. Never mind the already vulnerable SCADA systems out there, etc. What a PITA.