News New BootHole Vulernability Revealed: Impacts 'Billions' of Devices

[Admin]

Eclypsium reveals a new BootHole vulernability as part of a coordinated disclosure with OS vendors and computer manufacturers.

New BootHole Vulernability Revealed: Impacts 'Billions' of Devices : Read more

 

[drtweak]

Wonder if reflashing the BIOS would remove it?

 

[mitch074]

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.

 

[Soaptrail]

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?

 

[mogster]

If the problem lies within GRUB2, then how exactly does this affect Windows systems?

 

[InvalidError]

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.

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.

 

[mogster]

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

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.

 

[USAFRet]

.... or at least a UAC prompt.

As enabled by all the idiots who d/l and install pirated software and activation schemes.

 

[TJ Hooker]

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.

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.

 

[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?

 

[nofanneeded]

I never liked the move to UEFI Bios anyways . I wish that old bios comes back.

 

[Deleted member 14196]

Sounds pretty grubby

 

[InvalidError]

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?

If you want to use protected mode, you need to have tiered protection levels and that requires something close to a full-blown OS to manage. You don't have an OS to manage all that extra stuff at POST-time. At the earliest part of the boot process, you don't even have a working memory controller and the BIOS code has to work entirely from registers.

 

[neojack]

Can someone knowledgable explain if this attack is possible on those scenarios :

- old PC in BIOS-only

- recent PC in "legacy/CSM" boot

- recent PC in UEFI boot, but secure boot disabled


I think the attack defeats the secure boot, behaving like it's disabled, correct ?

in this case i think UEAFI with secure boot disabled is vulnerable to this kind of attack since the begining, correct ?

 

[InvalidError]

I think the attack defeats the secure boot, behaving like it's disabled, correct ?

Not quite. The point of secure boot is to provide a "chain of trust" from boot and the GRUB2 exploit enables someone to inject code without being detected. If you turned secure boot off, an OS configured to enforce secure boot would complain that the system has been compromised. Secure boot is still on and behaving normally, only difference is that it cannot tell it has been compromised.

 

[warezme]

I ran into an issue related to this a couple of months ago, not the virus but a corrupt EFI boot partition. I learned several things. One is your EFI - UEFI partition DOES NOT need to reside on your Windows data disk and your boot drive also DOES NOT need to be GPT enabled. It seems in the many years of upgrading the OS across multiple drives I ended up with a non standard UEFI boot configuration. The act of moving drives around caused my UEFI partition to get scrambled.

The takeway is you can RECREATE your UEFI 100MB hidden parition on a separate drive, assign it a higher letter like V: or S: to avoid drive shuffle AND place it on whatever drive you want to make GPT. If this doesn't confuse some standard level hack I don't know what will.

 

[Chung Leong]

If you want to use protected mode, you need to have tiered protection levels and that requires something close to a full-blown OS to manage. You don't have an OS to manage all that extra stuff at POST-time. At the earliest part of the boot process, you don't even have a working memory controller and the BIOS code has to work entirely from registers.

Nowadays, the L2 cache inside CPUs are large enough to host a proper protected mode kernel. It seems if we want to, we can toss out the decades-old legacy stuff. Most programmers only know the flat-memory model (if they think about it at all). Continued reliance on real mode is really sort of unwise.

 

[InvalidError]

Nowadays, the L2 cache inside CPUs are large enough to host a proper protected mode kernel. It seems if we want to, we can toss out the decades-old legacy stuff. Most programmers only know the flat-memory model (if they think about it at all). Continued reliance on real mode is really sort of unwise.

Even if you use cache for boot-time memory, you still cannot boot straight into protected mode since protected mode needs to be setup first, which means everything running in flat ring-0 until then and is effectively the same as running real-mode security-wise.