New BootHole Vulnerability Revealed, Impacts Billions of Devices
Turns out Secure Boot is not secure
Eclypsium, a company that specializes in enterprise security solutions, revealed a new vulnerability that allows attackers to gain near-total control of WIndows or Linux systems. The company says that billions of devices are vulnerable, like systems ranging from laptops, desktop PCs, servers, and workstations, to other types of devices, like special-purpose equipment used in industrial, healthcare, financial, and other industries. The announcement comes as part of a coordinated industry-wide disclosure.
The attack exposes a vulnerability in the UEFI Secure Boot framework that normally prevents unauthorized access to the system during boot time. By compromising Secure Boot, attackers can then use malicious UEFI bootloaders to gain unfettered access and control of the system. Luckily, this attack requires elevated privileges to exploit (but not physical access), which means it would be hard for outside entities to attack a system without some level of insider knowledge or having already gained access to credentials through other means.
However, once compromised, the system appears to operate as normal even though malware has complete access to the system and OS. The malicious code then resides in the bootloader, and thus will persist even after re-installing the operating system. The vulnerability (CVE-2020-10713) has been assigned a CVSS rating of 8.2, meaning attackers can exploit the vulnerability to gain near-total access to a device.
UEFI Secure Boot is an industry standard that protects almost all servers and PCs from attacks during the system boot-up process, and all systems equipped with Secure Boot are impacted - even if the feature isn't enabled.
Secure Boot uses cryptographic signatures to verify each type of code that is allowed to run during the boot up process. The GRUB2 (Grand Unified Bootloader) handles loading the system and transferring control to the OS during boot time, and if this process is compromised, attackers can gain full control of the system.
As a basic explanation (read here for technical deep dive), the BootHole attack exploits a buffer overflow vulnerability in the GRUB2 configuration file, which is a text file that isn't protected like other files and executables. This allows for arbitrary code execution within GRUB2, and thus allows the attacker to swap in malicious bootloaders that allow attackers full access to the system.
The announcement comes as part of a coordinated disclosure with OS vendors, computer manufacturers, and CERTs, many of which Eclypsium says will release individual announcements today. Those companies include Microsoft, Oracle, Red Hat, Canonical (Ubuntu), SuSE, Debian, Citrix, VMware, and a spate of various OEMs and software vendors.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
The company projects the vulnerability will take some time to be patched for all systems, with various entities announcing their own schedules for patch releases. Per the company:
"Mitigation is complex and can be risky and will require the specific vulnerable program to be signed and deployed, and vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack. The three-stage mitigation process will likely take years for organizations to complete patching."
Paul Alcorn is the Managing Editor: News and Emerging Tech for Tom's Hardware US. He also writes news and reviews on CPUs, storage, and enterprise hardware.
-
mitch074
No - you would need to reformat the boot disk, including its boot sectors, and reset the CMOS.drtweak said:Wonder if reflashing the BIOS would remove it? -
Soaptrail
this text file is on the OS hard drive not the BIOS of the motherboard?mitch074 said:No - you would need to reformat the boot disk, including its boot sectors, and reset the CMOS. -
InvalidError
The way the article is written, it sounds like they are exploiting a buffer overflow in GRUB2's config text file parsing for arbitrary code execution and then using that to install UEFI modules in BIOS. So you need elevated privilege initially to install GRUB2 if not already present and put the malicious config file on.Soaptrail said:this text file is on the OS hard drive not the BIOS of the motherboard?
GRUB2 is used as a signed container to deliver the exploit via config file buffer overflow to avoid breaking the secure boot chain and triggering warnings or prevent booting. Someone with sufficient access privileges could temporarily install GRUB2 on your Windows system long enough to install UEFI modules and remove it afterward to make the system look normal again with the UEFI payload still present in BIOS.mogster said:If the problem lies within GRUB2, then how exactly does this affect Windows systems? -
mogster
Yes, from what I can tell the grub.cfg is stored in the hidden EFI partition of a GPT-formatted disk. It's typically 100 MB, and Windows won't let you mount it, but it can be mounted in Linux.Soaptrail said:this text file is on the OS hard drive not the BIOS of the motherboard?
DISKPART> select disk 3
Disk 3 is now the selected disk.
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Recovery 529 MB 1024 KB
Partition 2 System 100 MB 530 MB
Partition 3 Reserved 16 MB 630 MB
Partition 4 Primary 446 GB 646 MB
DISKPART> select part 2
Partition 2 is now the selected partition.
DISKPART> detail part
Partition 2
Type : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden : Yes
Required: No
Attrib : 0X8000000000000000
Offset in Bytes: 555745280
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 9 FAT32 Partition 100 MB Healthy System
I'm not sure how that would work. It sounds like it would require physical access or at least a UAC prompt.InvalidError said:GRUB2 is used as a signed container to deliver the exploit via config file buffer overflow to avoid breaking the secure boot chain and triggering warnings or prevent booting. Someone with sufficient access privileges could temporarily install GRUB2 on your Windows system long enough to install UEFI modules and remove it afterward to make the system look normal again with the UEFI payload still present in BIOS. -
USAFRet
As enabled by all the idiots who d/l and install pirated software and activation schemes.mogster said:.... or at least a UAC prompt. -
TJ Hooker
As far as I can tell, all you'd need to do is delete the malicious grub.cfg file. Although given this vulnerability requires root/administrator access to your PC, you'd obviously want to take additional steps to secure it.drtweak said:Wonder if reflashing the BIOS would remove it?
Reading the Eclypsium article, I don't think this is the case. GRUB isn't used to deliver the exploit, GRUB is the exploit (in conjunction with a malicious .cfg file). The attacker needs elevated privileges to install GRUB (if not already the bootloader in use) and modify the .cfg. I don't see anything in the article about modifying the actual UEFI FW on the motherboard.InvalidError said:GRUB2 is used as a signed container to deliver the exploit via config file buffer overflow to avoid breaking the secure boot chain and triggering warnings or prevent booting. Someone with sufficient access privileges could temporarily install GRUB2 on your Windows system long enough to install UEFI modules and remove it afterward to make the system look normal again with the UEFI payload still present in BIOS. -
Chung Leong No NX protection in real mode, I guess. Why the heck do PCs still boot in real mode anyway? The 386 was introduced like what, 30 years ago?Reply