Oplysninger om to sårbarheder i GRUB2-bootloaderen er blevet afsløret, som kan føre til udførelse af kode ved brug af specielt formaterede skrifttyper og behandling af bestemte Unicode-sekvenser. Sårbarhederne kan udnyttes til at omgå mekanismen for verificeret opstart UEFI Secure Boot.
Identificerede sårbarheder:
- CVE-2022-2601 — buffer overflow i funktionen grub_font_construct_glyph() ved behandling af specielt designede skrifttyper i pf2-format, som opstår på grund af forkert beregning af parametret max_glyph_size og tildeling af et hukommelsesområde, der er åbenlyst mindre end nødvendigt for at rumme glyphs.
- CVE-2022-3775 — skrivning uden for det tildelte hukommelsesområde ved gengivelse af visse Unicode-sekvenser med en specielt designet skrifttype. Problemet er til stede i skrifthåndteringskoden og skyldes manglen på passende kontroller for overensstemmelse mellem glyphs bredde og højde og størrelsen på den eksisterende bitmap. En angriber kan konstruere input, så det fremkalder skrivning af datavidere på grænsen af det tildelte buffer. Det bemærkes, at på trods af sværhedsgraden ved udnyttelse af sårbarheden, kan udførelse af kode ikke udelukkes.
Fixet er blevet offentliggjort som en patch. Status for sårbarhedslukning i distributioner kan vurderes på disse sider: Ubuntu, SUSE, RHEL, Fedora, Debian. For at løse problemerne i GRUB2 er det ikke tilstrækkeligt blot at opdatere pakken, det er også nødvendigt at lave nye interne digitale signaturer og opdatere installatører, bootloaders, kernelpakker, fwupd-firmwares og shim-lag.
I de fleste Linux-distributioner anvendes et lille shim-lag, der er digitalt signeret af Microsoft, til verificeret boot i UEFI Secure Boot-tilstand. Dette lag verificerer GRUB2 med sit eget certifikat, hvilket gør det muligt for distributionsudviklere ikke at skulle signere hver opdatering af kernen og GRUB i Microsoft. Sårbarheder i GRUB2 tillader eksekvering af egen kode efter en vellykket verifikation af shim, men før operativsystemet er indlæst, ved at trænge ind i tillidskæden under aktiv Secure Boot-tilstand og få fuld kontrol over den fortsatte bootproces, herunder nedlæsning af et andet OS, ændring af komponenter i operativsystemet og omgåelse af Lockdown-beskyttelsen.
For at blokere sårbarheden uden at tilbagekalde den digitale signatur kan distributionerne anvende mekanismen SBAT (UEFI Secure Boot Advanced Targeting), som understøttes af GRUB2, shim og fwupd i de fleste populære Linux-distributioner. SBAT er udviklet i samarbejde med Microsoft og indebærer tilføjelse af metadata til UEFI-komponenternes eksekverbare filer, som inkluderer oplysninger om producent, produkt, komponent og version. De nævnte metadata signeres digitalt og kan separat inkluderes i lister over tilladte eller forbudte komponenter til UEFI Secure Boot.
SBAT gør det muligt at blokere brugen af den digitale signatur for specifikke versionsnumre af komponenter uden at skulle tilbagekalde nøglerne til Secure Boot. Blokering af sårbarheder gennem SBAT kræver ikke brugen af en liste over tilbagekaldte UEFI-certifikater (dbx), men udføres på niveauet for udskiftning af den interne nøgle til dannelse af signaturer og opdatering af GRUB2, shim og andre boot-artifakter, der leveres af distributionerne. Inden SBAT blev indført, var opdatering af listen over tilbagekaldte certifikater (dbx, UEFI Revocation List) en obligatorisk betingelse for fuld blokering af sårbarheden, da en angriber, uanset hvilken operativsystem der blev brugt, kunne bruge en bootbare enhed med en gammel, sårbar version af GRUB2, signeret med et digitalt certifikat, til at kompromittere UEFI Secure Boot.
Kilde: opennet.ru
