IT administrators are being warned to watch for patches from Microsoft, Linux distributors, and major software makers to patch a serious buffer flow vulnerability in the bootloader process of enterprise operating systems.
In a report issued Wednesday security vendor Eclypsium warns almost every Windows and Linux system using Secure Boot, including network appliances and special-purpose equipment used in industrial, healthcare, financial and other industries, is at risk.
“Mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack,” says the report. “This will likely be a long process and take considerable time for organizations to complete patching.”
Until updates are issued, IT admins should start monitoring the contents of the bootloader partition (EFI system partition) of their operating systems for abnormalities, says Eclypsium.
Ars Technica argues the vulnerability may not be critical. An attacker must have either administrative rights over a target computer or physical access to the machine. And, it argues, if an attacker has administrative or physical control of a computer, there are lots of other ways to infect a machine.
The problem is in almost all signed versions of the GRUB2 Secure Boot bootloader in most Linux systems, as well as any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. GRUB2 also supports other operating systems, kernels and hypervisors such as Xen.
Attackers exploiting this vulnerability can install persistent and stealthy bootkits or malicious bootloaders that could give them near-total control over the victim device, says the report. Last month security vendor ESET said it had discovered several malicious EFI bootloader samples that display a ransom message and prevent an infected computer from booting.
Eclypsium says full mitigation of the vulnerability will take time because it involves Microsoft, Linux distributions, and others. GRUB2 will need to be updated, Linux distributors will have to update their installers, bootloaders, and shims, new shims will need to be signed by the Microsoft 3rd Party UEFI certificate authority, IT administrators will not only have to update their IT and OT device operating systems but also disaster recovery media (a shim contains a vendor’s certificate and code that verifies and runs the bootloader).
Eventually, the report adds, the UEFI (Unified Extensible Firmware Interface) revocation list (known as the Secure Boot Forbidden Signature Database or dbx) needs to be updated in the firmware of each affected system to prevent running vulnerable code during boot.
Full deployment of this revocation process will likely be very slow, says the report, in part because UEFI-related updates have had a history of making devices unusable and therefore vendors will need to be very cautious. If the revocation list is updated before a given Linux bootloader and shims are updated, then the operating system will not load. As a result, updates to the revocation list will take place over time to prevent breaking systems that have yet to be updated.
Other problems may crop up with dual-boot or deprovisioned machines, or enterprise disaster recovery processes where approved recovery media no longer boots on a system if UEFI database updates have been applied. Before dbx updates are pushed out to enterprise fleet systems, says the report, recovery and installation media must be updated and verified as well.
UEFI Secure Boot was originally developed by the UEFI Forum as a way to protect the boot process from attacks. IT uses cryptographic signatures to verify the integrity of each piece of code as it is needed during the boot process. Instead of having every OEM manage certificates from every possible firmware, driver, or OS provider, Secure Boot allows for the use of a centralized Certificate Authority (CA). Microsoft’s 3rd Party UEFI CA provides the industry-standard signing service for Secure Boot, so third parties can submit their code to Microsoft, and Microsoft validates and sign the code with the Microsoft CA.
In almost every modern Linux distribution, GRUB (the Grand Unified Bootloader) is the bootloader that loads and transfers control to the operating system.