In August 2020, a set of security vulnerabilities in GRUB2 (the GRand Unified Bootloader version 2) collectively known as BootHole were disclosed. Today, another set of vulnerabilities in GRUB2 were disclosed, with similar implications. Because GRUB2 is a key component of the boot process, vulnerabilities in it can permit attackers to violate the integrity promises of UEFI Secure Boot. In this blog post we will discuss these vulnerabilities as well as the changes that have been made to Ubuntu to both mitigate them, and to make the update process easier for any future similar scenarios.
As discussed back in August 2020, the UEFI Secure Boot process in Ubuntu is supported by a number of different components, all working together to ensure that only trusted bootloaders and operating systems are able to run. These consist of the UEFI platform firmware (aka UEFI BIOS), shim, the GRUB2 bootloader and the Linux kernel. The latter 3 of these are Ubuntu components, while the former is provided by the device OEM. In this case, both shim and GRUB2 have (or will soon receive updates) to mitigate these vulnerabilities and to help ensure older vulnerable versions of GRUB2 are not trusted by the secure boot process and cannot be used to load malicious code.
In the aftermath of the original BootHole disclosure, Chris Coulson from the Ubuntu Security team and external researchers each discovered additional vulnerabilities in GRUB2 which could be used to circumvent secure boot. Upon disclosing this to the upstream GRUB2 developers, a renewed effort to try and identify any additional vulnerabilities that were still lurking in GRUB2 was established. Through a combination of fuzz testing, static analysis and manual code inspection, a cross-industry team of security engineers from various organisations discovered in total 8 vulnerabilities in GRUB2 (6 of which affect Ubuntu) for this update, and each assigned a CVE as detailed below:
- CVE-2020-14372: grub2: acpi command allows privileged user to load crafted ACPI tables when secure boot is enabled
- CVE-2021-20233: grub2: heap out-of-bound write due to mis-calculation of space required for quoting
- CVE-2020-25632: grub2: use-after-free in rmmod command
- CVE-2020-27779: grub2: cutmem command allows privileged user to disable certain memory regions thereby disabling Secure Boot protections
- CVE-2021-20225: grub2: heap out-of-bounds write in short form option parser
- CVE-2020-27749: grub2: stack buffer overflow in grub_parser_split_cmdline
The seventh vulnerability was identified by Dimitri John Ledkov from the Ubuntu Foundations team – this only affected upstream GRUB2 but not Ubuntu (having previously been addressed during the BootHole update):
- CVE-2021-3418 – grub2: GRUB 2.05 reintroduced CVE-2020-15705, GRUB2 fails to validate kernel signatures when booted directly without shim, allowing secure boot to be bypassed.
The eighth vulnerability affected the GRUB2 USB module, which is not included in the modules bundled in Ubuntu’s signed EFI image, and thus does not affect Ubuntu:
- CVE-2020-25647: grub2: memory corruption from crafted USB device descriptors allows a local user to execute arbitrary code when secure boot is enabled
One GRUB2 to rule them all
To ensure a unified approach, the version of GRUB2 for UEFI systems used in older Ubuntu releases is updated so that a single GRUB2 version can be used for all – this ensures that both the latest security fixes and mitigation features can be more easily adopted in these older releases. As this has the potential to cause issues in what is a fundamental component of the boot process (due to the large number of changes in both GRUB2 itself as well as the way this is distributed in Ubuntu), this update will be carefully rolled out via the Updates pocket of the Ubuntu package archive.
Because Secure Boot does not apply to BIOS based boot environments, we will not be publishing updates for GRUB2 on those systems.
What has it got in its pocketses?
The Ubuntu package archive consists of a number of pockets for each Ubuntu release: release, security, updates and proposed. The release pocket contains those packages and their particular version which made up the initial release. The security pocket is used to provide security updates for packages. The proposed and updates pockets are used to provide bug-fix updates through the two-step Stable Release Updates process – first packages are uploaded to the proposed pocket and only after they have been sufficiently tested and validated, they then migrate to the updates pocket. The release, security and updates pockets are enabled by default on new Ubuntu installations but the proposed pocket is not – however, it can be enabled manually for testing and verification purposes. By splitting the Ubuntu archive between the updates and security pockets, this allows users who are more conservative to choose to receive only security (but not bug) fixes by disabling the updates pocket. These pockets differ not only by what is allowed in each pocket, but also by how package updates from each pocket are applied. To ensure timely delivery of security updates, new package versions released into this pocket are available immediately to end users, and tools like unattended-upgrades ensure these will be installed automatically on newer Ubuntu releases. In comparison, packages in the update pocket are released progressively to ensure that any possible regressions will only affect a small subset of users by halting updates for packages which are found to be problematic.
As this update touches packages which are critical for Ubuntu systems to boot successfully, they are being released via the proposed and then the updates pockets in this instance, to limit the impact of any possible regressions (however unlikely). Whilst this delays the delivery of the update for GRUB2 to Ubuntu users, in this instance the impact of this delay is minimal as the associated update for shim itself is also delayed as discussed below.
One doesn’t simply revoke multiple GRUB2 binaries
In the previous GRUB2 update for BootHole an associated update for the UEFI DBX database was released by the UEFI Forum. The DBX database is used to enumerate components that should not be trusted during secure boot, but which would otherwise – in that instance it was used to enumerate the multiple older GRUB2 versions that were vulnerable to BootHole. However, the vast majority of platforms which support UEFI Secure Boot have only limited space to store this information, and the previous DBX update for BootHole consumed a significant amount of this storage – consuming all of the storage would render machines unbootable. As such, another mechanism was required to allow unsafe GRUB2 (or other boot components) to be enumerated so they would be disallowed from booting. Working in conjunction with Microsoft and others, a Secure Boot Advanced Targeting (SBAT) scheme was devised for shim, which provides a more flexible means to provide a list of GRUB2 (or other binaries) that should not be trusted as part of the secure boot process. In addition, shim supports the concept of an in-built vendor DBX, which allows shim distributors (such as Ubuntu) to ship their own list of binaries that should not be trusted. For this update, we have added the list of all older GRUB2 binaries shipped in Ubuntu that contain this new set of vulnerabilities as well as the versions that were vulnerable to the original BootHole vulnerabilities to this vendor DBX within shim as part of the updated shim package for Ubuntu..
Due to the short amount of time between the SBAT features being developed for shim and the desire to ensure these are stable, as well as the need for Microsoft to validate these for signing as a new trusted piece for secure boot, a coordinated delayed release of shim has been established, as such these associated updates for shim are expected to be available within a few weeks of the GRUB2 updates. It should also be noted that unlike in the previous BootHole related update for GRUB2 in Ubuntu, for this update the previous shim binaries that were signed by Microsoft for Ubuntu will now be added to the upstream UEFI Forum DBX revocation list. This was not done during the BootHole update since instead the certificate which was used to sign those old GRUB2 binaries itself was revoked. To complete this transition, this old certificate will now be added to shim’s vendor DBX in addition to the GRUB2 binaries mentioned above.
Finally, we also expect to release an update for fwupd in Ubuntu. This package is used to install UEFI firmware updates and is also trusted as a secure boot component, as such it requires an update to support SBAT as well.
There and back again…
When the original BootHole vulnerabilities were first announced, this shone a spotlight on UEFI Secure Boot and in particular GRUB2 as part of that ecosystem. Whilst a strong effort was made at that time to try and enumerate and resolve all similar possible vulnerabilities in GRUB2, this was an unfinished task. This latest round of updates seeks to resolve both newly discovered vulnerabilities as well as make the process for any future such updates an easier journey for both Ubuntu developers and end-users alike. For more information on these updates, please visit the article within the Ubuntu Security Knowledge Base.