NSA issues BootHole mitigation guidance
Connecting state and local government leaders
Following the disclosure of a widespread vulnerability that could affect potentially billions of Linux and Windows-based devices, the National Security Agency issued a cybersecurity advisory highlighting the bug and offering steps for mitigation.
Following the disclosure of a widespread buffer-flow vulnerability that could affect potentially billions of Linux and Windows-based devices, the National Security Agency issued a follow-up cybersecurity advisory highlighting the bug and offering steps for mitigation.
The vulnerability -- dubbed BootHole -- impacts devices and operating systems that use signed versions of the open-source GRUB2 bootloader software found in most Linux systems. It also affects any system or device using Secure Boot -- a root firmware interface responsible for validating the booting process -- with Microsoft's standard third party certificate authority. The vulnerability enables attackers to bypass Secure Boot to allow arbitrary code execution and “could be used to install persistent and stealthy bootkits,” NSA said in a press statement.
The researchers who discovered the bug said that the impact would likely be vast, encompassing possibly billions of devices. NSA concurred, saying BootHole "poses a risk to a majority of Linux distributions and systems running on Windows 8 or later versions," including national security, Defense Department and defense industrial base systems. "Impact may include but is not limited to public/private cloud instances, data center servers, end-user desktops/laptops, and Linux-based Operational Technology/Internet of Things devices," the agency said.
Patching will likely be slow, difficult and full of breakdowns due to the complexity of systems involved, according to the Eclypsium researchers who found the bug. This has already been borne out as by some companies detailed unexpected breakdowns rolling out initial fixes.
While the disclosure came with an update to GRUB2, it won't be a simple patch job, and switching in the newer version will almost certainly come with a number of collateral interoperability problems. Revoking vulnerable versions of the bootloader is also expected to be challenging.
The NSA advisory offers organizations two options for mitigation as well as detection guidance for vulnerable or abnormally configured versions of the bootloader. For the "typical" consumer, business and enterprise environments, the agency recommends patching the endpoint and revoking trust for vulnerable versions of the bootloader or shim applications. However, changes must be made carefully.
"Fully mitigating the BootHole vulnerability requires multiple steps that must be performed in a specific order to update and revoke the trust for existing signed boot components," the agency wrote. "Failure to ensure each step is completed before proceeding to the next step may result in an endpoint no longer being able to boot while Secure Boot is enabled."
There is also an "advanced" mitigation option recommended for business and enterprise endpoints with higher security and integrity requirements that involves customizing Secure Boot to allow Microsoft and other vendors to minimize or remove certificates. The notice references a forthcoming technical report that will provide more details on this method. An NSA spokesperson said that document is still being worked on and there is no immediate timetable for its public release.
Because it may take some time for organizations effectively test all OEMs, models and firmware revisions in their endpoints, NSA recommended administrators monitor changes to firmware, firmware configuration and boot components.
"If you're an IT administrator in an enterprise and you have tens of thousands of systems, maybe you have 10 different models of servers and 10 different models of laptops deployed throughout your fleet," said Jesse Michael, one of Eclypsium's principal researchers who discovered the bug. "You want to test [the patch] on each of these individual types of devices, specific models with specific firmware versions, before you actually deploy it out to the fleet, because if you deploy something out to your data center with thousands of servers and there's a firmware bug that causes those not to come up again, you're going to have a bad day."
This report combines two articles first posted to FCW, a sibling site to GCN.
NEXT STORY: Locking down 5G