New BootHole Vulnerability Revealed, Impacts Billions of Devices

(Image credit: Eclypsium)

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.

(Image credit: Eclypsium)

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. 

(Image credit: Eclypsium)

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.

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
Managing Editor: News and Emerging Tech

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.

  • drtweak
    Wonder if reflashing the BIOS would remove it?
    Reply
  • mitch074
    drtweak said:
    Wonder if reflashing the BIOS would remove it?
    No - you would need to reformat the boot disk, including its boot sectors, and reset the CMOS.
    Reply
  • Soaptrail
    mitch074 said:
    No - you would need to reformat the boot disk, including its boot sectors, and reset the CMOS.
    this text file is on the OS hard drive not the BIOS of the motherboard?
    Reply
  • mogster
    If the problem lies within GRUB2, then how exactly does this affect Windows systems?
    Reply
  • InvalidError
    Soaptrail said:
    this text file is on the OS hard drive not the BIOS of the motherboard?
    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.

    mogster said:
    If the problem lies within GRUB2, then how exactly does this affect Windows systems?
    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.
    Reply
  • mogster
    Soaptrail said:
    this text file is on the OS hard drive not the BIOS of the motherboard?
    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.
    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
    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.
    I'm not sure how that would work. It sounds like it would require physical access or at least a UAC prompt.
    Reply
  • USAFRet
    mogster said:
    .... or at least a UAC prompt.
    As enabled by all the idiots who d/l and install pirated software and activation schemes.
    Reply
  • TJ Hooker
    drtweak said:
    Wonder if reflashing the BIOS would remove it?
    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.

    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.
    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.
    Reply
  • 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
  • nofanneeded
    I never liked the move to UEFI Bios anyways . I wish that old bios comes back.
    Reply