Important Info on Boothole Vulnerability - ThreatWire
Added 2020-08-04 18:31:09 +0000 UTCThreatWire is only possible because of our Patreon patrons! Sign up now for ACTION ALERTS! Help me reach our next ThreatWire goal to unlock merch tiers and an audio podcast! https://www.patreon.com/threatwire
BootHole is a new critical vulnerability that affects billions of devices around the world. It resides in the GRUB2 bootloader and can allow an attacker to bypass Secure Boot and gain privileged, persistent stealth access to systems. Boothole is being tracked as CVE-2020-10713 and was found by security researchers at Eclypsium, an enterprise security company.
On machines, Secure Boot is used to load up important components including the operating system and ensures that the boot process itself is cryptographically sound by only allowing proper authorized code to boot. It’s built into the UEFI so users don’t even really see what’s happening on the backend. GRUB2 handles everything by automatically booting into the OS, but all techies have had to mess around in UEFI at one point or another. Secure Boot keeps machines safe during that bootup process. But, BootHole is a buffer overflow and it affects all versions of GRUB2, hitting the bootloader in the config file, which researchers noted is not signed in the same way as other files, and can leave a door open for attackers to break that bootloader trust.
Also of note is the fact that an attacker would already need to compromise the device in some way in order to take advantage of this attack. They would already need administrative privileges. As an example, an attacker could use another vulnerability to replace the default bootloaders with vulnerable versions of GRUB2 to exploit BootHole. Physical access could be necessary in order to replace the regular files with malicious ones. Since this happens during the boot process, anti-malware software on an operating system may not detect the malicious code.
To fix this issue, it’s not as simple as just patching the systems via software, since attackers could replace the bootloader altogether. New bootloaders would need to be signed and deployed, while vulnerable ones would need to be revoked completely. Each affected system would need updated lists of revoked bootloaders, and new ones would need to be signed by certificate authorities. It’s a process. Even hardware makers need to get involved in the event they provision their own factory keys and versions of GRUB2. Many distros are releasing advisories including Microsoft, Red Hat, Canonical (for Ubuntu), Debian and more but mitigations and timelines for patches could take a very long time since updates to bootloaders often make older machines unstable or even unusable. Microsoft, for example, has stated in their own reports that they’ll make updates available for interested parties but won’t push an update since it could brick some devices. Interested orgs and admins should test devices to ensure they are recoverable before trying to push updates.
Some manufacturers have started implementing updates, and we’re seeing unbootable patched machines. For example, Red Hat has an available patch but it’s making devices running RHEL 7.8 and 8.2 stop booting entirely. CentOS’s patch is also rendering it unresponsive. So now Red Hat is saying “don’t apply the patches” until they can fix these issues. More reports of issues with the patch started rolling in from other manufacturers and distros including Ubuntu, Debian, and Fedora. So, be careful out there. And have a backup plan.
BootHole:
https://thehackernews.com/2020/07/grub2-bootloader-vulnerability.html
https://threatpost.com/billions-of-devices-impacted-secure-boot-bypass/157843/
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
https://www.zdnet.com/article/linux-distros-fix-new-boothole-bug/
https://www.zdnet.com/article/boothole-fixes-causing-boot-problems-across-multiple-linux-distros/
