How to stop hacking… before the OS starts up
The latest bug to strike before the operating system starts up has received the nickname “Boothole” and Eclypsium researchers, Mickey Shkatov and Jesse Michael, discovered the flaw.
Boothole affects the integrity of the boot-up process itself, allowing hackers to execute code that runs the next time a device starts. And can happen even with Secure Boot enabled. Eclypsium found the vulnerability in the GRUB2 bootloader that most Linux systems use.
Worse is that the flaw affects systems using Secure Boot, even if they are not using GRUB2. Almost all signed versions of GRUB2 are vulnerable, meaning it affects virtually every Linux distribution. GRUB2 also supports other operating systems, kernels and hypervisors such as Xen.
If you think Windows systems aren’t’ affected, think again as the issue also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. This covers most laptops, desktops, servers and workstations. Even network appliances and other special purpose equipment used in industrial, healthcare, financial and other industries are affected.
The detail of the devils
The problem starts with a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg). According to researchers, the GRUB2 config file is a text file and typically is not signed like other files and executables.
“This vulnerability enables arbitrary code execution within GRUB2 and thus control over the booting of the operating system. As a result, an attacker could modify the contents of the GRUB2 configuration file to ensure that attack code is run before the operating system is loaded. In this way, attackers gain persistence on the device,” said researchers in a blog post.
They said that all signed versions of GRUB2 that read commands from an external grub.cfg file are vulnerable, affecting every Linux distribution.
What can I do?
The basics, to start with, but also… researchers said that organisations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders and firmware and verifying UEFI configurations, including revocation lists, in their systems.
“Organisations should also test recovery capabilities as updates become available, including the “reset to factory defaults” functionality in the UEFI setup. This will ensure that they can recover devices if a device is negatively impacted by an update,” said researchers.
Help is not on its way
An unnamed CISO at a financial institution based in the City of London, told SC Media that many systems run by banks use Linux and this will be a big problem for banks and other organisations.
“We really need to get patches from the vendors pretty sharpish but I can’t see them coming out any time soon as bootloader bugs are complex to patch,” they said. “At the moment, all we can realistically do is monitor EFI system partition to detect unexpected changes, particularly to the GRUB2 configuration file grub.cfg.”
Martin Jartelius, CSO at Outpost24, told SC Media that organisations should turn off legacy BIOS if you are one of few where this threat is the priority problem to resolve. “But for every normal enterprise, review users with root access and have a working patch-and-vulnerability management programme in place,” he said.
William Rimington, managing director, cyber risk at global investigations firm Kroll, told SC Media that Secure Boot provides security features that are unavailable on legacy BIOS hardware.
“CISOs should work with their system administrators and security teams to replace vulnerable legacy systems, identify mitigating factors till manufacturers release updated UEFI revocation lists – and begin tests on software and operating system updates needed to use updated Secure Boot hardware,” he said.
