Responsible disclosure and coordinated response as a benefit to all

Today we released USN-4432-1 announcing updates for a series of vulnerabilities termed BootHole / ‘There’s a hole in the boot’ in GRUB2 (GRand Unified Bootloader version 2) that could allow an attacker to subvert UEFI Secure Boot. The original vulnerability, CVE-2020-10713, which is a high priority vulnerability was alerted to Canonical in April 2020. Since then seven related vulnerabilities have been discovered by Canonical and we have worked with the wider open source community and Microsoft to provide the mitigations which have been released today for Ubuntu and other major Linux distributions. 

In this blog post, we will explain more about the vulnerabilities and a behind-the-scenes look about how they were fixed in a coordinated manner across the entire open source ecosystem. To discover the in-depth details of the CVEs and the updated packages which fix the associated vulnerabilities, please visit our Ubuntu Security Knowledge Base article. 

To understand the scope of this vulnerability we have to examine the boot process from Secure Boot to Grub. UEFI Secure Boot is designed to ensure that only trusted code is loaded during the boot process. As such, these vulnerabilities could have potentially allowed an attacker to compromise the boot process of the machine, and subvert it for malicious purposes. GRUB2 is used as the bootloader for Ubuntu and many other Linux distributions on both installed systems and installation media. In addition, these vulnerabilities have been present in GRUB2 for quite a long time. In other words, there are a large number of Linux releases and installed instances that could be vulnerable. A high profile vulnerability with such a widespread presence presents a significant challenge to protecting systems and users. For example, how to ensure that security updates can be delivered in a timely manner to both patch the vulnerability on as many existing systems as possible, but to also ensure that any old, vulnerable Linux install media cannot be used in the future to attack existing systems. This requires a coordinated approach across the community of Linux distributions, and also the wider UEFI community including Microsoft and others. 

The Canonical Security Team was first contacted by researchers from Eclypsium at the start of April 2020 detailing a vulnerability in GRUB2 which was believed to allow an attacker to subvert UEFI Secure Boot. The Canonical Security team immediately redirected the researchers to report the issue directly to the upstream GRUB2 maintainers, recognising this could have much wider applicability than just Ubuntu. Two weeks later, GRUB2 maintainers contacted Canonical and other affected downstream Linux distributions to begin the approach of resolving the vulnerability in a coordinated fashion. CVE-2020-10713 was quickly assigned by Red Hat to identify the vulnerability and a candidate patch to fix the vulnerability was proposed. The next step was to set a Co-ordinated Release Date (CRD) – an agreed upon date and time that details of the vulnerability would be made public. After some discussion, a final CRD of 17:00 UTC on 29th July, 2020 was decided. With the end-goal in place, it was then time to start digging into the details of what would actually be required to resolve the vulnerability.

Unlike other security vulnerabilities, where the software update can be released and installed to remediate the vulnerability , the nature of UEFI Secure Boot created significant complications.  UEFI Secure Boot uses a trust model that is generally anchored with Microsoft. For Windows compliance, PCs must ship the Microsoft UEFI Signing Certificate as a trust anchor, meaning that anything which Microsoft has deemed trusted and signed with this certificate will be allowed to be booted via UEFI Secure Boot. In the case of many Linux distributions, a small binary – a shim – is signed by Microsoft and this is then used to load GRUB2 to actually boot the Linux kernel and so on. Linux distributions ship their own trusted certificate within their shim binaries, and this is used to validate that GRUB2 is appropriately signed by the distribution and hence trusted as part of the UEFI Secure Boot process. As mentioned earlier, these shim and GRUB2 binaries are also used on the various installation media to ensure they can be booted when UEFI Secure Boot is enabled. These old install media would then always be trusted, even though they contain this vulnerable version of GRUB2 and hence could be used to bypass UEFI Secure Boot on any system. Luckily, the UEFI specification provides a way to distrust either particular certificates or particular binaries by adding entries into the UEFI forbidden signature database (DBX). However, adding entries to this database again requires that new entries are signed by a valid trust anchor – i.e. Microsoft. As such, a large degree of coordination was required between the various Linux distributions and Microsoft to ensure the latter could provide this signed list of vulnerable and hence forbidden GRUB2 binaries / certificates to ensure that systems cannot be exploited in the future via old install media.

During this process with Microsoft, Canonical and others also took the opportunity to look for other possible existing vulnerabilities in GRUB2 so that, as one party put it; “we don’t have to be back here again in 2 weeks”. Through a combination of static code analysis and manual inspection, Chris Coulson (Canonical) and Colin Watson (Canonical and maintainer of GRUB2 in Debian) discovered a number of further vulnerabilities (CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15706, and CVE-2020-15707, respectively). Finally, one previously known outstanding vulnerability in GRUB2 (CVE-2020-15705), discovered by Mathieu Trudel-Lapierre (previously of Canonical) was also fixed as part of this update. This provided a total of 8 vulnerabilities which then needed to be patched across the various Ubuntu releases of GRUB2 to fix these issues on existing systems.

The final pieces of the puzzle then were to prepare and test the patched GRUB2 builds, as well as the signed DBX update from Microsoft. Chris Coulson and Dimitri John Ledkov (Canonical) handled most of the heavy lifting on these, with additional support from the OEM Enablement Team at Canonical to ensure these updates could be delivered without risk of regression.

Throughout this process there has also been a lot of work behind the scenes to coordinate with OEMs and other vendors who ship Ubuntu, as well as the cross-distribution coordination discussed above. All of these efforts have helped to ensure that Ubuntu  and other major Linux distributions could ensure their users were also protected as well at the point of the CRD. This approach is a true reflection of the meaning of the word Ubuntu, I am because we are, and demonstrates a fundamental strength of the shared ecosystem of Linux and free and open-source software.

If you would like to know more details regarding these vulnerabilities and the updated packages which fix it, the associated Ubuntu Security KnowledgeBase article should be your first port-of-call.