Cybersecurity and Hole in the Boot

The computers and systems we use at work and at home have to be secure. We work on confidential, sensitive projects, and have PII on these every single day. This data being released into the wild or for sale on the dark web would be a truly bad thing for everyone involved. For business, there is also liability and fines which may be a concern. These can be rather significant with certain industries (e.g. healthcare). There is not a way around this. With the systems, cybersecurity has to be in place from the beginning of the operation. There can’t be a lag. Any time this is not in place, the attack surface expands for the attacker to examine. As the system starts, the boot process kicks in and begins the operations. A recent attack focused on this part of the process. The new exploit is a bootkit, since it resides in the bootloaders. The new attack has been named “There’s a Hole in the Boot”.

The problem at hand is with the bootloader process of the enterprise OS. In Linux systems, the vulnerability is in the Grand Unified Boot Loader (GRUB). Most programs use a program (i.e. shim) to extend the trust from the firmware to other programs securing early during the boot process. The particular issue is with the configuration parser in GRUB2 (grub.cfg) not properly exiting when there are errors present. This is exploitable when you increase the size of a token with the grub.cfg. This results in a heap-based buffer overflow. This acts to break the chain of trust. At this point, the attacker may download a non-signed (e.g. malicious) programs during this time in the boot process.

In Microsoft systems, the successful attack allows arbitrary code to be executed and UEFI (Unified Extensible Firmware Interface) Secure Boot restrictions bypassed. In the Microsoft systems, the UEFI was engineered by the UEFI Consortium to protect the boot process from attacks. This ensures only the immutable and signed software is uploaded during the boot process and not malicious code, which in theory makes it “secure”. The attack allows the attacker to execute arbitrary code and bypass the UEFI Secure Boot restrictions.

The secure boot has two steps, which are checking the allow (DB) and disallow (DBX) databases. These are just as they appear. The allow database (DB) holds the hashes and keys for the trusted loaders and EFI applications. These are allowed to be loaded onto the machine’s firmware. Naturally, the disallowed database (DBX) holds the revoked, compromised, and hashes/keys that are no longer trusted. The boot process fails when any signed code on the DBX is presented.

The attack affects many different systems and versions. In particular, this is targeted to Enterprise Linux 7 and 8, Red Hat Atomic Host, Openshift Container Platform 4 (RHEL CoreOS), Windows 10, 8.1, Server 2012, Server 2019, Server 1903, Server 1909, and Server 2004.

Issue

This is a rather significant issue. This was researched by the security vendor Eclypsium. As the responsible cybersecurity researchers, they did coordinate the disclosure of the issue. The firm notified Microsoft, Linux distributors (Red Hat, SuSE, Canonical/Ubuntu, and Debian), Citrix, VMware, computer original equipment manufacturers, and software developers. This may seem like a rather broad brush with notifying all of the organizations and groups. The risk with the issue is rather large though. Nearly every Windows and Linux system using secure boot is at risk. This also affects network appliances, proprietary gear specific to healthcare, financial and other industries, internet-of-things (IoT), operational technology (OT), and SCADA equipment in industrial environments. Once this is exploited, the attackers are able to bypass the secure boot process that is supposed to guard the system and disable other code integrity checks. Once this is done the attackers are able to load arbitrary executables and drivers. The attacker, once this is done, could nearly take over the complete system.

To hack or not to hack, that is the question

This appears to be a rather serious problem, with billions of devices at risk. This attack is not as easy as other attacks. To exploit this, you would need to have admin rights/root OR physical access to a system. If an unauthorized person has access and admin rights or physical access to a live system, you probably have larger systemic problems than this. This also has a limited level of relevance for most cloud computing uses, data centers, and personal devices. This has a limited application unless the system is already pwned

Mitigation

There are updates available for Ubuntu 20.04, 18.04, 16.04, and 14.04, and other systems. SuSE and Debian have released patches for this issue. Red Hat recommends updating their GRUB 2 packages. Red Hat clients using Secure Boot need to update the kernel, fwupdate, fwupd, shim, and dbxtool packages with the newly validated keys and certificates.

While these are great, this is not a quick fix. The mitigations will be a multi-step process and will take a long process and take significant time to complete the patches. In the interim, the admins need to monitor the contents of the bootloader partition (EFI system partition) for their OS, test the revocation list updates, deploy revocation updates, and engage with your third-party vendors to understand how they are addressing this issue

Resources

Auscert. (2020, July 30). There’s a hole in the boot. Retrieved from https://www.auscert.org.au/blog/2020-07-30-theres-a-hole-in-the-boot

Blinde, L. (2020, July 31). NSA warns of GRUB2 BootHole vulnerability. Retrieved from https://intelligencecommunitynews.com/nsa-warns-of-grub2-boothole-vulnerability/

Brink. (2020, July 29). BootHole vulnerability in secure boot affecting Linux and windows. Retrieved from https://www.tenforums.com/windows-10-news/161603-boothole-vulnerability-secure-boot-affecting-linux-windows.html

Canonical. (2020, July 29). USN-4432-1: GRUB 2 vulnerabilities. Retrieved from https://ubuntu.com/security/notices/USN-4432-1

Cimpanu, C. (2020, July 29). ‘BootHole’ attack impacts windows and Linux systems using GRUB2 and secure boot. Retrieved from https://www.zdnet.com/article/boothole-attack-impacts-windows-and-linux-systems-using-grub2-and-secure-boot/

Debian. (2020). GRUB2 UEFI SecureBoot vulnerability-‘BootHole’. Retrieved from https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/

Germain, J.M. (2020, July 29). New security hole puts windows and Linux users at risk. Retrieved from https://www.technewsworld.com/story/86778.html

Goodin, D. (2020, July 29). New flaw neuters secure boot, but there’s no reason to panic. Here’s why. Retrieved from https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/

Goetting, B. (2020, July 29). BootHole GRUB2 bootloader security exploit discovered, affects billions of windows and Linux devices. Retrieved from https://hothardware.com/news/eclypsium-boothole

Ilascu, I. (2020, July 29). BootHole GRUB bootloader bug lets hackers hide malware in Linux, windows. Retrieved from https://www.bleepingcomputer.com/news/security/boothole-grub-bootloader-bug-lets-hackers-hide-malware-in-linux-windows/

Kovacs, E. (2020, July 30). Companies respond to ‘BootHole’ vulnerability. Retrieved from https://www.securityweek.com/companies-respond-boothole-vulnerability

Kumar, M. (2020, July 29). Critical GRUB2 bootloader bug affects billions of Linux and windows systems. Retrieved from https://thehackernews.com/2020/07/grub2-bootloader-vulnerability.html

Meissner, M. (2020, July 27). SUSE addresses BootHole security exposure. Retrieved from https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/

Microsoft. (2020, July 29). ADV200011|Microsoft guidance for addressing security feature bypass in GRUB. Retrieved from https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011

Monathan, J. (2020, July 29). “Boothole” bootloader flaw breaks security on most Linux, windows devices. Retrieved from https://securityledger.com/2020/07/boothole-bootloader-flaw-breaks-security-on-most-linux-windows-devices/

Murphy, I. (2020, July 30). BootHole exposes billions of devices to attack. Retrieved from https://www.enterprisetimes.co.uk/2020/07/30/boothole-exploits-a-vulnerability-in-the-secure-boot-process-affecting-virtually-every-linux-distribution-windows-machine-and-other-operating-systems/

Red Hat Customer Portal. (2020, July 29). Boot hole vulnerability: GRUB 2 boot loader-CVE-2020-10713. Retrieved from https://access.redhat.com/security/vulnerabilities/grub2bootloader /78

Saarinen, J. (2020, July 30). Boothole GRUB2 bug breaks secure boot on Linux and windows. Retrieved from https://www.itnews.com.au/news/boothole-grub2-bug-breaks-secure-boot-on-linux-and-windows-551050

Seals, T. (2020, July 29). Billions of devices impacted by secure boot bypass. Retrieved from https://threatpost.com/billions-of-devices-impacted-secure-boot-bypass/157843/

Sheridan, K. (2020, July 29). ‘BootHole’ vulnerability exposes secure boot devices to attack. Retrieved from https://www.darkreading.com/vulnerabilities---threats/boothole-vulnerability-exposes-secure-boot-devices-to-attack/d/d-id/1338487

Solomon, H. (2020, July 30). IT admins being warned of vulnerability in secure boot process in Linux, windows. Retrieved from https://www.itworldcanada.com/article/it-admins-being-warned-of-vulnerability-in-secure-boot-process-in-linux-windows/433860

SUSE. (2020). Security vulnerability: “Boothole” grub2 UEFI secure boot lockdown bypass. Retrieved from https://www.suse.com/support/kb/doc/?id=000019673