A Team of the security company Eclypsium has discovered a vulnerability (CVE-2020-10713) in the free and very widespread boot loader Grub 2. The vulnerability is also known as a Boothole, because it can be used to circumvent the security measures of UEFI Secure Boot and to execute your own code in a so-called boot kit. With the help of Secure Boot exactly this attack scenario is supposed to be prevented.
The error itself is a buffer overflow in the way the configuration file (Grub2.cfg) is processed by the application itself. The vulnerability enables code to be executed in the boot loader itself, and thus theoretically full control over which system should be started.
With the option of changing the configuration file itself so that code is always executed before the operating system is started, malicious code can be permanently injected into a system. For a successful attack root or administration rights are required to be able to change the Grub2.cfg file.
Secure boot bypassable
With secure boot technology, boot loaders and operating systems are signed cryptographically. At the start these signatures are then compared with the keys of a database in the firmware of the computer. If the verification is successful, the system itself starts. If this does not succeed, for example because the keys have been withdrawn, Secure Boot should actually prevent the system from starting. But this verification mechanism can now be handled with Boothole.
Years ago, the parties involved agreed that Microsoft, as the central certificate authority (CA), could be used for secure boot by third parties so that not every Linux distributor had to negotiate with each manufacturer individually for storing keys and certificates. Almost all currently popular versions of operating systems with the boot loader Grub are signed by this CA. This leads to a strange problem regarding updates for the gap.
The Boothole vulnerability is relatively easy to fix itself and corresponding updates can be distributed with a new signature. In addition, however, the computer database must be updated to check the verification and the previously used certificates must be withdrawn so that vulnerable Grub2 versions that were previously signed can no longer be used for attacks in the future. However, if both are executed in the wrong order, this can lead to a system that can no longer be started.
The Linux distributors involved, other Grub users, Microsoft and the UEFI Forum are currently coordinating the further procedure. So there is already one updated revocation list with withdrawn certificates from the UEFI Forum. Microsoft itself recommends for Windows and for its own devices that the Microsoft CA be revoked for third parties, provided that its own firmware allows this.
The update of the entire affected ecosystem is probably very complex and will take some time. In order to prevent this from happening again soon, the participating distributors and security companies searched for further errors in Grub 2 in a large-scale campaign that enable similar attacks, and finally found a large number of them.
According to the Linux distribution Debian, this also includes errors in handling ACPI tables by the Linux kernel. Details can be found at the individual manufacturers and distributors such as Debian, Canonical, Red Hat, Suse, HP, HPE or VMware.