Wednesday, July 29th 2020
New BootHole Vulnerability Affects Billions of Devices, Compromises GRUB2 Boot-loader
Even if you don't have more than one operating system installed, your PC has a boot-loader, a software component first executed by the system BIOS, which decides which operating system to boot with. This also lets users toggle between different run-levels or configurations of the same OS. The GRUB2 boot-loader is deployed across billions of computers, servers, and pretty much any device that uses a Unix-like operating system. Cybersecurity researchers with Oregon-based firm Eclypsium, discovered a critical vulnerability with GRUB2 that can compromise a device's operating system. They named the vulnerability BootHole. This is the same firm behind last year's discovery of the Screwed Drivers vulnerability. It affects any device that uses the GRUB2 boot-loader, including when combined with Secure Boot technology.
BootHole exploits a design flaw with two of the key components of GRUB2, bison, a parser generator, and flex, a lexical analyzer. Eclypsium discovered that these two can have "mismatched design assumptions" that can lead to buffer overflow. This buffer overflow can be exploited to execute arbitrary code. Devices with modern UEFI and Secure Boot enabled typically wall off even administrative privileged users off from tampering with boot processes, however, in case of BootHole, the boot-loader parses a configuration file located in the EFI partition of the boot device, which can be modified by any user (or malicious process) that has admin privileges. Thankfully, patched versions of GRUB2 are already out, and the likes of SUSE have started distributing it for all versions of SUSE Linux. Expect practically every other *nix vendor, server manufacturer, to release patches to their end-users. Find a technical run-down of the vulnerability in this PDF by Eclypsium.
Source:
HotHardware
BootHole exploits a design flaw with two of the key components of GRUB2, bison, a parser generator, and flex, a lexical analyzer. Eclypsium discovered that these two can have "mismatched design assumptions" that can lead to buffer overflow. This buffer overflow can be exploited to execute arbitrary code. Devices with modern UEFI and Secure Boot enabled typically wall off even administrative privileged users off from tampering with boot processes, however, in case of BootHole, the boot-loader parses a configuration file located in the EFI partition of the boot device, which can be modified by any user (or malicious process) that has admin privileges. Thankfully, patched versions of GRUB2 are already out, and the likes of SUSE have started distributing it for all versions of SUSE Linux. Expect practically every other *nix vendor, server manufacturer, to release patches to their end-users. Find a technical run-down of the vulnerability in this PDF by Eclypsium.
45 Comments on New BootHole Vulnerability Affects Billions of Devices, Compromises GRUB2 Boot-loader
Open source is first about people. For some reason you keep talking about like a bean counter. Not that it's a bad thing, but it's a really, really narrow understanding of what open source is.
It's not. It's something people are doing in their spare time (you're interrupting me from my Android project right now), it's something that is both written and studied in universities, it's something you at your job if you're paid to. It can even be something you do in your spare time because it helps you at your job.
And if you want to make a living off open source, you do that by charging for support. Or by extending your open source project with non-open functionality.Please, not that idiocy again. I've already told you in this industry 80% of the project fail anyway.
Back on topic, I've actually tried this vulnerability(I run several devices that have GRUB2 installed). It's a kick to the jimmies at best to make it work right and there is no way in heaven or hell someone is remoting in to do it, at least based on the scenario's described by the data sheet and what I tried. Granted, I'm not the most freaky-neeky crackster in the world, but it's just not feasible to take advantage of the "hole-in-the-boot" unless the system in question is an extremely high value target and there are no easier avenues of exploit(which is unlikely).