TL;DR
The BootHole vulnerability is not critical (yet), but it could potentially affect billions of devices worldwide. Exploiting it requires high privileges or physical access. Now while there are no full patches available at this time, we’ve written this blog, and published this episode of The Vulnerability Report, to help you detect vulnerable devices, mitigate the risk and prepare a plan for long-term remediation.
What is the GRUB2 BootHole Vulnerability (CVE-2020-10713)?
BootHole (CVE-2020-10713) is a new high-risk vulnerability that can potentially effect billions of devices worldwide, from servers and workstations to laptops, desktops and IoT systems running nearly any Linux distribution or Windows system.
BootHole resides in the GRUB2 bootloader. If exploited, it could potentially allow hackers bypass the Secure Boot feature, designed explicitly to prevent unauthorized code from gaining additional privileges and pre-OS persistence. Thus, the attacker would gain high-privileged persistent and stealthy access to those targeted systems.
How to fix the BootHole vulnerability
The BootHole vulnerability in Windows can be fixed by downloading the dbxupdate_x64.bin file, creating a folder under C:\Temp\Powershell\DBX and placing the scripts and file there, then running the PowerShell script. Additionally, Microsoft has released a standalone Secure Boot update listed in KB4576750[2] and SUSE has switched to a new secure boot signing key for secure boot signed images. Disabling Windows SecureBoot is also an option, though not ideal.
See if you are vulnerable to BootHole
Use these Powershells and bash scripts from Eclypsium to detect if bootloaders that are being revoked by this dbxupdate.
Vendors Security Advisories for BootHole
While the fully fixing this vulnerability remains to be out of sight for the time being, here are some vendor’s advisories for CVE-2020-0713 that could mitigating the risk until the vulnerability be fully fixed:
Microsoft
Microsoft are currently “working to complete validation and compatibility testing of a required Windows Update that addresses this vulnerability.”
Mitigations:
1. Reconfigure Secure Boot: Microsoft Surface provides the capability to configure Secure Boot with or without trust in 3rd-party UEFI CA. Surface customers who do not require the 3rd-party UEFI CA can configure Secure Boot as ‘Microsoft only’ as a mitigation to this issue. Learn more here.
WARNING: Modification of UEFI Secure Boot configuration can trigger BitLocker Recovery and failures in other security software. Be sure to suspend BitLocker and have your BitLocker Recovery Key available if you are performing this operation.
2. Manually install untested DBX update: Working with the Linux community, Microsoft has released an untested update to address this vulnerability. This optional DBX update has received limited testing and is intended for IT professionals and enthusiasts. The update is hosted by the UEFI Forum at: https://uefi.org/revocationlistfile.
WARNING Installation of this patch on incompatible
Red Hat
Red Hat recommends that “all customers to update their grub2 packages. Red Hat customers using Secure Boot need to update kernel, fwupdate, fwupd, shim and dbxtool packages containing newly validated keys and certificates. Users running Secure Boot with Red Hat Enterprise Linux 8 need to take additional steps to boot into previously released RHEL 8 kernels after applying the grub2 package updates. See the RHEL 8 section here for more details.”
Red Hat have released a Diagnose script, and an Ansible playbook for updating all relevant packages:
1. Diagnose script: to determine if your system is currently vulnerable to this flaw. Download the script here.
To verify the authenticity of the script, download the detached OpenPGP signature.
Ansible Playbook: This Ansible playbook, CVE-2020-10713-update_fixit.yml updates all relevant packages. Download the script here. To use the playbook, specify the hosts you’d like to update with the HOSTS extra var:
| ansible-playbook -e HOSTS=<myhosts> CVE-2020-10713-update_fixit–2020-07-29-1613.yml |
To verify the legitimacy of the playbook, you can download the detached OpenPGP signature.
*IMPORTANT UPDATE: Red Hat and CentOS systems aren’t booting due to BootHole patches*
Red hat announced: “System hangs after POST and the grub menu never loads after applying the RHSA-2020:3216 or RHSA-2020:3217”
Affected versions:
Confirmed in the following releases
- Red Hat Enterprise Linux (RHEL) 7.8
- Red Hat Enterprise Linux (RHEL) 8.2
NOT confirmed in the following releases but potentially affected
- Red Hat Enterprise Linux (RHEL) 8.1 EUS
- Red Hat Enterprise Linux (RHEL) 7.9
If you have already updated the packages, please follow Red Hat guide to downgrade back the packages here. Please note that the solution is still unverified so test it first before spreading.
3. Ubuntu
Ubuntu recommends updating your system to the following package versions:
| Ubuntu 20.04 | Ubuntu 18.04 | Ubuntu 16.04 | Ubuntu 14.04 |
| * grub-efi-amd64-bin – 2.04-1ubuntu26.1 * grub-efi-amd64-signed – 1.142.3+2.04-1ubuntu26.1 * grub-efi-arm-bin – 2.04-1ubuntu26.1 *grub-efi-arm64-bin – 2.04-1ubuntu26.1 * grub-efi-arm64-signed – 1.142.3+2.04-1ubuntu26.1 * grub-efi-ia32-bin – 2.04-1ubuntu26.1 |
* grub-efi-amd64-bin – 2.02-2ubuntu8.16
* grub-efi-amd64-signed – 1.93.18+2.02-2ubuntu8.16
* grub-efi-arm-bin – 2.02-2ubuntu8.16
* grub-efi-arm64-bin – 2.02-2ubuntu8.16
* grub-efi-arm64-signed – 1.93.18+2.02-2ubuntu8.16
* grub-efi-ia32-bin – 2.02-2ubuntu8.16
* grub-efi-ia64-bin – 2.02-2ubuntu8.16
* grub-efi-amd64-bin – 2.02~beta2-36ubuntu3.26
* grub-efi-amd64-signed – 1.66.26+2.02~beta2-36ubuntu3.26
* grub-efi-arm-bin – 2.02~beta2-36ubuntu3.26
* grub-efi-arm64-bin – 2.02~beta2-36ubuntu3.26
* grub-efi-arm64-signed – 1.66.26+2.02~beta2-36ubuntu3.26
* grub-efi-ia32-bin – 2.02~beta2-36ubuntu3.26
* grub-efi-ia64-bin – 2.02~beta2-36ubuntu3.26
* grub-efi-amd64-bin – 2.02~beta2-9ubuntu1.20
* grub-efi-amd64-signed – 1.34.22+2.02~beta2-9ubuntu1.20
* grub-efi-arm-bin – 2.02~beta2-9ubuntu1.20
* grub-efi-arm64-bin – 2.02~beta2-9ubuntu1.20
* grub-efi-ia32-bin – 2.02~beta2-9ubuntu1.20
* grub-efi-ia64-bin – 2.02~beta2-9ubuntu1.20
They also claim that “Fully mitigating these vulnerabilities requires both an updated GRUB2 boot loader and the application of a UEFI Revocation List (dbx) to system firmware. Ubuntu will provide a packaged dbx update at a later time, though system administrators may choose to apply a third party dbx update before then”. For more details on mitigation steps and the risks entailed (especially for dual/multi-boot scenarios), see attached Knowledge Base article“.
Other Vendors KB:
Building a Long-Term Remediation Strategy for BootHole
As there is no quick fix to BootHole, it’s worth building a long-term remediation strategy that will result in effectively mitigating the risk over time.
It’s worth mentioning that in order to exploit BootHole, attackers must have admin or elevated privileges or physical access to the device. As so, the risk that this vulnerability poses could potentially be lower.
Patching vulnerabilities of this kind is usually risky and often takes time to apply. According to Eclypsium “full deployment of this revocation process will likely be very slow. UEFI-related updates have had a history of making devices unusable, and vendors will need to be very cautious. If the revocation list (dbx) is updated before a given Linux bootloader and shim 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.“
Recommended actions moving forwards:
- Detect the vulnerable assets and tag them internally. Note OS type and version as patches may vary.
- Prioritize privilege escalation vulnerabilities on the vulnerable assets.
- Test the related OS updates thoroughly before applying them across the organization. Review them online in credible sources to make sure instances won’t break.
- Test the revocation list update. Be sure to specifically test the same firmware versions and models that are used in the field. It may help to update to the latest firmware first in order to reduce the number of test cases.
- Make sure that all bootable media has received OS updates first before you deploy the revocation update. Roll it out slowly to a small number of devices at a time and incorporate lessons learned from testing as part of this process.
- Create an action plan to remediate the vulnerability when updates are available, start with small batches before rolling out to the entire organization.
Resources used in this article: https://thehackernews.com/2020/07/grub2-bootloader-vulnerability.html?m=1
