I driver, der muliggør arbejdet med NTFS-filsystemet i GRUB2-bootloaderen, har en sårbarhed (CVE-2023-4692), der gør det muligt at udføre vilkårlig kode på bootloaderniveau ved at tilgå et specielt tilpasset filsystembillede. Sårbarheden kan bruges til at omgå mekanismen for verificeret opstart UEFI Secure Boot.
Sårbarheden skyldes en fejl i koden, der analyserer NTFS-attributten «$ATTRIBUTE_LIST» (grub-core/fs/ntfs.c), som kan udnyttes til at skrive kontrollerede brugeroplysninger i hukommelsesområdet uden for den tildelte buffer. Ved behandling af et specielt tilpasset NTFS-billede fører overfyldning til overskrivning af dele af GRUB-hukommelsen, og under visse forhold kan det også skade UEFI-firmwarehukommelsesområdet, hvilket potentielt muliggør udførelse af vilkårlig kode på bootloader- eller firmware-niveau.
Derudover er der også blevet identificeret en anden sårbarhed (CVE-2023-4693) i NTFS-driveren fra GRUB2, der gør det muligt at læse indholdet af et vilkårligt hukommelsesområde, når «$DATA»-attributten analyseres i et specielt tilpasset NTFS-billede. Blandt andet tillader sårbarheden udtræk af fortrolige data, der er cached i hukommelsen, eller bestemmelse af værdierne for EFI-variabler.
Problemerne er hidtil kun blevet løst i form af en patch. Status for udbedring af sårbarheder i distributioner kan vurderes på følgende sider: Debian, Ubuntu, SUSE, RHEL, Fedora. For at løse problemerne i GRUB2 er det ikke nok kun at opdatere pakken; det er også nødvendigt at generere nye interne digitale signaturer og opdatere installatører, bootloadere, kernpakker, fwupd-firmware og shim-laget.
I de fleste Linux-distributioner bruges et lille lag shim, som er digitalt signeret af Microsoft, til verifikation af opstart i UEFI Secure Boot-tilstand. Dette lag verificerer GRUB2 med sin egen certifikat, hvilket giver distributørerne mulighed for ikke at skulle godkende 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 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 videre opstartsproces, for eksempel til at indlæse et andet OS, modificere komponenter i operativsystemet og omgå 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 giver mulighed for at blokere anvendelsen af digitale signaturer for specifikke versioner af komponenter uden behov for at tilbagekalde nøgler til Secure Boot. Blokering af sårbarheder gennem SBAT kræver ikke brug af listen 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 leverede distributionsbootartefakter. Inden indførelsen af SBAT var opdatering af listen over tilbagekaldte certifikater (dbx, UEFI Revocation List) en obligatorisk betingelse for fuldstændig blokering af sårbarheden, da en angriber, uanset hvilket operativsystem der blev brugt, kunne udnytte bootloaderen til at kompromittere UEFI Secure Boot.
Kilde: opennet.ru
