Oplysninger om 8 sårbarheder i bootloaderen GRUB2 er blevet offentliggjort, som gør det muligt at omgå UEFI Secure Boot og køre ikke-verificeret kode, eksempelvis ved at implementere malware, der opererer på bootloader- eller kerne-niveau.
Vi minder om, at en lille shim-lag, der er verificeret med en digital signatur fra Microsoft, anvendes til verificeret boot i UEFI Secure Boot-tilstand i de fleste Linux-distributioner. Denne shim verificerer GRUB2 med sin egen certifikat, hvilket gør det muligt for udviklere af distributioner ikke at skulle signere hver opdatering af kerne og GRUB hos Microsoft. Sårbarheder i GRUB2 gør det muligt at udføre sin egen kode efter en vellykket verificering af shim, men før operativsystemet bliver indlæst, ved at trænge ind i tillidkæden, mens Secure Boot er aktiv, og dermed få fuld kontrol over den videre boot-proces, herunder indlæsning af et andet operativsystem, modificering af komponenter i operativsystemet og omgåelse af Lockdown-beskyttelsen.
Som med den tidligere BootHole-sårbarhed er det ikke tilstrækkeligt at opdatere bootloaderen for at blokere problemet, da en angriber, uanset hvilket operativsystem der anvendes, kan bruge et bootmedium med en gammel sårbar version af GRUB2, der er verificeret med en digital signatur, til at kompromittere UEFI Secure Boot. Problemet løses kun ved at opdatere listen over tilbagekaldte certifikater (dbx, UEFI Revocation List), men i dette tilfælde vil muligheden for at bruge gamle installationsmedier med Linux gå tabt.
På systemer med firmware, der har opdateret listen over tilbagekaldte certifikater, vil det kun være muligt at indlæse opdaterede builds af Linux-distributioner i UEFI Secure Boot-tilstand. Distributioner skal opdatere deres installatører, bootloaders, kernepakker, fwupd-firmware og shim-lag, og generere nye digitale signaturer til disse. Brugere skal opdatere installationsbilleder og andre bootmedier samt indlæse listen over tilbagekaldte certifikater (dbx) i UEFI-firmware. Inden dbx er opdateret i UEFI, forbliver systemet sårbart, uanset om opdateringer er installeret i operativsystemet. Status for udbedring af sårbarheder kan vurderes på følgende sider: Ubuntu, SUSE, RHEL, Debian.
For addressing issues that arise from the distribution of revoked certificates, a mechanism called SBAT (UEFI Secure Boot Advanced Targeting) is planned to be utilized in the future. Support for this mechanism has been implemented for GRUB2, shim, and fwupd, and starting with the next updates, it will be used instead of the functionality provided by the dbxtool package. SBAT has been developed in collaboration with Microsoft and involves adding new metadata to the executable files of UEFI components, which includes information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can additionally be included in the lists of allowed or denied components for UEFI Secure Boot. Thus, SBAT will allow for manipulating version numbers of components upon revocation without the need to regenerate keys for Secure Boot and without forming new signatures for the kernel, shim, grub2, and fwupd.
Identificerede sårbarheder:
- CVE-2020-14372 — using the acpi command in GRUB2, a privileged local system user can load modified ACPI tables by placing an SSDT (Secondary System Description Table) in the /boot/efi directory and modifying settings in grub.cfg. Despite Secure Boot being active, the proposed SSDT will be executed by the kernel and can be used to disable the LockDown protection, which blocks UEFI Secure Boot bypass paths. As a result, an attacker may achieve the loading of their kernel module or execute code through the kexec mechanism, without a digital signature check.
- CVE-2020-25632 — a use-after-free access in the implementation of the rmmod command that manifests when attempting to unload any module without considering its dependencies. The vulnerability does not prevent creating an exploit that could lead to executing code bypassing Secure Boot verification.
- CVE-2020-25647 — buffer overflow in the grub_usb_device_initialize() function called during USB device initialization. The issue can be exploited by connecting a specially prepared USB device that presents parameters whose size does not match the buffer size allocated for USB structures. An attacker may achieve the execution of code that is not verified in Secure Boot through manipulations with USB devices.
- CVE-2020-27749 — buffer overflow in the grub_parser_split_cmdline() function, which can be triggered by specifying variables larger than 1 KB in the GRUB2 command line. The vulnerability allows for code execution bypassing Secure Boot.
- CVE-2020-27779 — the cutmem command allows an attacker to remove a range of addresses from memory to bypass Secure Boot.
- CVE-2021-3418 — changes in shim_lock created an additional vector for exploiting last year's vulnerability CVE-2020-15705. When installing a certificate used for signing GRUB2 in dbx, GRUB2 allowed any kernel to be loaded directly without signature verification.
- CVE-2021-20225 — the possibility of writing data outside the buffer when executing commands with a very large number of options.
- CVE-2021-20233 — the possibility of writing data out of bounds due to incorrect buffer size calculation when using quotes. The size calculation assumed that escaping a single quote required three characters, while four are actually needed.
Kilde: opennet.ru
