The latest bug to attack prior to the operating system starting has been allocated the name “Boothole”, & Eclypsium researchers, Mickey Shkatov & Jesse Michael, discovered the problem.
‘Boothole’ bug has shown the ease in taking over systems when they are starting – this has become a cause of additional risk for CISOs..
‘Boothole’ affects the integrity of the boot-up process itself, letting hackers execute code that runs the next time on device start-up. This can happen even with Secure Boot enabled. Eclypsium discovered the vulnerability in the GRUB2 bootloader used by the majority of Linux systems.
Secure Boot
This problem affects systems using Secure Boot, even whilst not using GRUB2. The majority of signed versions of GRUB2 are said to be vulnerable, so it affects virtually every Linux distribution. GRUB2 also supports additional operating systems, kernels & hypervisors e.g. Xen.
For those believing that Windows systems are unaffected, this is not true, as this problem also reaches any Windows device using Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.
This is most laptops, desktops, servers & workstations. Also, network appliances & other special purpose equipment used in industrial, healthcare, financial & other industries are affected too.
GRUB2
The problem begins with a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg). Says researchers, the GRUB2 config file is a text file, & usually is not signed like other files & executables.
“This vulnerability enables arbitrary code execution within GRUB2 & thus control over the booting of the operating system.
Configuration File
So, an attacker could change the contents of the GRUB2 configuration file to make sure that attack code is run before the operating system is loaded. Thus, attackers gain persistence on the device,” outlined researchers in a blog post.
All signed versions of GRUB2 that read commands from an external grub.cfg file are vulnerable, affecting every Linux distribution.
Appropriate Capabilities
Researchers further commented that organisations should also ensure they have ‘appropriate capabilities’ for monitoring UEFI bootloaders, & firmware, & 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,” remarked researchers.
Undisclosed CISO
An undisclosed CISO at a City of London financial institution, revealed that many systems run by banks use Linux, & this will be a big problem for banks & 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 explained. “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.”
Outpost 24
Martin Jartelius, CSO at Outpost 24, observed that organisations should turn off legacy BIOS if you are one of a few where this threat is the priority. “But for every normal enterprise, review users with root access & have a working patch-&-vulnerability management programme in place,” he commented.
William Rimington, MD, Cyber Risk at worldwide investigations firm Kroll, observed that Secure Boot provides security features that are simply unavailable on legacy BIOS hardware.
“CISOs should work with their system administrators & security teams to replace vulnerable legacy systems, identify mitigating factors till manufacturers release updated UEFI revocation lists & begin tests on software & operating system updates needed to use updated Secure Boot hardware,” he explained.
