Der er blevet afsløret oplysninger om to sårbarheder i GRUB2 bootloaderen, som kan føre til kodeudførelse ved brug af specialdesignede skrifttyper og behandling af visse Unicode-sekvenser. Sårbarheder kan bruges til at omgå den UEFI Secure Boot-verificerede opstartsmekanisme.
Identificerede sårbarheder:
- CVE-2022-2601 - Et bufferoverløb i funktionen grub_font_construct_glyph() ved behandling af specialdesignede skrifttyper i pf2-formatet, hvilket opstår på grund af en forkert beregning af parameteren max_glyph_size og allokeringen af et hukommelsesområde, der åbenlyst er mindre end nødvendigt for at rumme glyfferne.
- CVE-2022-3775 En out-of-bounds-skrivning opstår, når nogle Unicode-sekvenser gengives i en specialstilet skrifttype. Problemet ligger i skrifttypebehandlingskoden og er forårsaget af mangel på korrekt kontrol for at sikre, at bredden og højden af glyfen matcher størrelsen af den tilgængelige bitmap. En angriber kan udforme inputtet på en sådan måde, at det forårsager, at halen af dataene bliver skrevet til ydersiden af den allokerede buffer. Det bemærkes, at på trods af kompleksiteten i at udnytte sårbarheden, er det ikke udelukket at bringe problemet til kodekørsel.
Rettelsen er blevet udgivet som en patch. Status for eliminering af sårbarheder i distributioner kan vurderes på disse sider: Ubuntu, SUSE, RHEL, Fedora, Debian. For at løse problemer i GRUB2 er det ikke nok bare at opdatere pakken; du skal også generere nye interne digitale signaturer og opdatere installationsprogrammer, bootloadere, kernepakker, fwupd-firmware og shim-lag.
De fleste Linux-distributioner bruger et lille shim-lag digitalt signeret af Microsoft til verificeret opstart i UEFI Secure Boot-tilstand. Dette lag verificerer GRUB2 med sit eget certifikat, som gør det muligt for distributionsudviklere ikke at få alle kerne- og GRUB-opdateringer certificeret af Microsoft. Sårbarheder i GRUB2 giver dig mulighed for at opnå eksekvering af din kode på stadiet efter vellykket shim-verifikation, men før du indlæser operativsystemet, kiler ind i tillidskæden, når Secure Boot-tilstanden er aktiv og får fuld kontrol over den videre opstartsproces, inkl. indlæsning af et andet OS, ændring af operativsystemets komponenter system og omgå Lockdown-beskyttelse.
For at blokere sårbarheden uden at tilbagekalde den digitale signatur kan distributioner bruge SBAT-mekanismen (UEFI Secure Boot Advanced Targeting), som understøttes for GRUB2, shim og fwupd i de fleste populære Linux-distributioner. SBAT er udviklet i fællesskab med Microsoft og involverer tilføjelse af yderligere metadata til de eksekverbare filer af UEFI-komponenter, som omfatter oplysninger om producent, produkt, komponent og version. De angivne metadata er certificeret med en digital signatur og kan inkluderes separat på listerne over tilladte eller forbudte komponenter til UEFI Secure Boot.
SBAT giver dig mulighed for at blokere brugen af digitale signaturer for individuelle komponentversionsnumre uden at skulle tilbagekalde nøgler til Secure Boot. Blokering af sårbarheder via SBAT kræver ikke brug af en UEFI-certifikattilbagekaldelsesliste (dbx), men udføres på niveau med at erstatte den interne nøgle for at generere signaturer og opdatere GRUB2, shim og andre boot-artefakter leveret af distributioner. Før introduktionen af SBAT var opdatering af certifikattilbagekaldelseslisten (dbx, UEFI Revocation List) en forudsætning for fuldstændig at blokere sårbarheden, da en angriber, uanset hvilket operativsystem der bruges, kunne bruge opstartsmedier med en gammel sårbar version af GRUB2, certificeret af en digital signatur for at kompromittere UEFI Secure Boot .
Kilde: opennet.ru