En sårbarhet (CVE-2023-4692) er identifisert i driveren som støtter NTFS-filsystemet i GRUB2-oppstartslasteren. Denne sårbarheten tillater kjøring av tilpasset kode på oppstartslasternivå når man åpner et spesiallaget filsystembilde. Denne sårbarheten kan utnyttes til å omgå den bekreftede oppstartsmekanismen for UEFI Secure Boot.
Sårbarheten skyldes en feil i parsekoden for NTFS-attributtet «$ATTRIBUTE_LIST» (grub-core/fs/ntfs.c), som kan utnyttes til å skrive brukerstyrt informasjon til en minneplassering utenfor den tildelte bufferen. Når et spesiallaget NTFS-bilde behandles, fører overflyten til at deler av GRUB-minnet overskrives, og under visse forhold ødelegges UEFI-fastvareminnet, noe som potensielt tillater kodekjøring på oppstartslaster- eller fastvarenivå.
Videre ble det oppdaget en annen sårbarhet (CVE-2023-4693) i NTFS-driveren i GRUB2. Denne sårbarheten tillater lesing av vilkårlig minneinnhold når attributtet "$DATA" analyseres i et spesiallaget NTFS-bilde. Blant annet tillater denne sårbarheten utvinning av sensitive data som er bufret i minnet eller bestemmelse av EFI-variabelverdier.
Problemene har så langt bare blitt løst gjennom oppdateringer. Status for sikkerhetsrettinger i distribusjoner kan vurderes på disse sidene: Debian, Ubuntu, SUSE, RHEL, Fedora. Å fikse GRUB2-problemer krever mer enn bare å oppdatere pakken; det krever også generering av nye interne digitale signaturer og oppdatering av installasjonsprogrammer, oppstartslastere, kjernepakker, fwupd-fastvare og shim-laget.
I de fleste LinuxDistribusjoner for verifisert oppstart i UEFI Secure Boot-modus bruker et lite shim-lag, digitalt signert av Microsoft. Dette laget verifiserer GRUB2 med sitt eget sertifikat, noe som eliminerer behovet for at distribusjonsutviklere må varsle Microsoft om hver kjerne- og GRUB-oppdatering. Sårbarheter i GRUB2 tillater vilkårlig kodekjøring etter vellykket shim-verifisering, men før operativsystemet starter opp. Dette lar angripere bryte seg inn i tillitskjeden når Secure Boot er aktivert og få full kontroll over den påfølgende oppstartsprosessen, for eksempel for å starte opp et annet operativsystem, endre operativsystemkomponenter eller omgå Lockdown-beskyttelse.
For å blokkere sårbarheten uten å tilbakekalle den digitale signaturen, kan distribusjoner bruke SBAT-mekanismen (UEFI Secure Boot Advanced Targeting), som støttes av GRUB2, shim og fwupd i de fleste populære distribusjoner. LinuxSBAT ble utviklet i samarbeid med Microsoft og innebærer å legge til ytterligere metadata i UEFI-komponentens kjørbare filer, inkludert informasjon om produsent, produkt, komponent og versjon. Disse metadataene er digitalt signert og kan inkluderes separat i listen over tillatte eller nektede komponenter for UEFI Secure Boot.
SBAT tillater blokkering av bruk av digitale signaturer for individuelle komponentversjonsnumre uten behov for å tilbakekalle Secure Boot-nøkler. Blokkering av sårbarheter via SBAT krever ikke bruk av UEFI Certificate Revocation List (dbx), men utføres på nivået med å erstatte den interne nøkkelen for å generere signaturer og oppdatere GRUB2, shim og andre oppstartsartefakter levert av distribusjoner. Før introduksjonen av SBAT var oppdatering av UEFI Revocation List (dbx) en obligatorisk betingelse for å fullstendig blokkere sårbarheten, siden en angriper, uavhengig av hvilket operativsystem som ble brukt, kunne bruke oppstartsnøkkelen til å kompromittere UEFI Secure Boot.
Kilde: opennet.ru
