nylig Informasjon om 8 sårbarheter i GRUB2-opplasteren ble utgittAt gjør det mulig å omgå UEFIs sikre oppstartsmekanisme og få kjørt ubekreftet kodeFor eksempel å injisere skadelig programvare som kjører på bootloader- eller kjernnivå.
Husk at i de fleste Linux-distribusjoner, for verifisert oppstart i UEFI sikker oppstartsmodus, brukes et lite kompensasjonslag sertifisert av en Microsoft digital signatur.
Dette laget verifiserer GRUB2 mot sitt eget sertifikat, slik at utviklere ikke kan sertifisere hver kjerne og oppdatere fra GRUB til Microsoft.
Med det sårbarheter i GRUB2 tillater at koden din kjøres i etterverifasen vellykket utbedring, men før operativsystemet lastes, passer inn i kjeden av tillit når Secure Boot er aktiv og får full kontroll over den påfølgende oppstartsprosessen, inkludert oppstart av et annet operativsystem, modifiser komponentsystemet i operativsystemet og omgå beskyttelseslåsen .
Som i tilfelle BootHole-sårbarheten fra i fjor, oppdatering av bootloader er ikke nok til å blokkere problemetSom en angriper, uansett operativsystem som brukes, kan du bruke oppstartsmedier med en gammel sårbar versjon av GRUB2, sertifisert med digital signatur, for å kompromittere UEFI Secure Boot.
Problemet løses bare ved å oppdatere listen over tilbakekalte sertifikater (dbx, UEFI Revocation List), men i dette tilfellet vil muligheten til å bruke gamle installasjonsmedier med Linux gå tapt.
På systemer med firmware der listen over tilbakekalte sertifikater er oppdatert, kan oppdaterte sett med Linux-distribusjoner bare lastes inn i UEFI Secure Boot-modus.
Distribusjoner må oppdatere installatører, bootloaders, kjernepakker, fwupd firmware og kompensasjonslaget ved å generere nye digitale signaturer for dem.
Brukere må oppdatere installasjonsbilder og andre oppstartsmedier og last ned sertifikatets tilbakekallingsliste (dbx) i UEFI-firmware. Inntil dbx-oppdateringen i UEFI forblir systemet sårbart uansett installasjon av oppdateringer i operativsystemet.
For å løse de avledede problemene av distribusjon av tilbakekalte sertifikater, det er planlagt å bruke SBAT-mekanismen i fremtiden (UEFI Secure Boot Advanced Targeting), som nå støtter GRUB2, shim og fwupd, og vil erstatte funksjonaliteten som tilbys av dbxtool-pakken i fremtidige oppdateringer. SBAT var utviklet i samarbeid med Microsoft for å legge til nye metadata til UEFI-komponentens kjørbare filer, som inkluderer produsent-, produkt-, komponent- og versjonsinformasjon.
Av de identifiserte sårbarhetene:
- CVE-2020-14372- Med acpi-kommandoen på GRUB2 kan den privilegerte brukeren på det lokale systemet laste inn modifiserte ACPI-tabeller ved å plassere en SSDT (sekundær systembeskrivelsestabell) i / boot / efi-katalogen og endre innstillingene i grub.cfg.
- CVE-2020-25632: tilgang til et minneområde som allerede er frigjort (bruk etter gratis) i implementeringen av rmmod-kommandoen, som manifesteres når du prøver å laste ned en hvilken som helst modul uten å ta hensyn til dens tilknyttede avhengigheter.
- CVE-2020-25647: Skriv ut av buffergrenser i grub_usb_device_initialize () -funksjonen som kalles når du initialiserer USB-enheter. Problemet kan utnyttes ved å koble til en spesielt forberedt USB-enhet som genererer parametere som ikke samsvarer med størrelsen på bufferen som er tildelt for USB-strukturer.
- CVE-2020-27749: bufferoverløp i grub_parser_split_cmdline () som kan være forårsaket av å spesifisere variabler større enn 1 KB på GRUB2-kommandolinjen. Sårbarheten kan tillate kjøring av kode uten å gå gjennom Secure Boot.
- CVE-2020-27779: kommandoen cutmem lar en angriper fjerne en rekke adresser fra minnet for å omgå sikker oppstart.
- CVE-2021-3418: endringer i shim_lock opprettet en ekstra vektor for å utnytte fjorårets CVE-2020-15705 sårbarhet. Ved å installere sertifikatet som ble brukt til å signere GRUB2 i dbx, tillot GRUB2 enhver kjerne å lastes direkte uten å bekrefte signaturen.
- CVE-2021-20225: muligheten til å skrive data ut av bufferen når du utfører kommandoer med et stort antall alternativer.
- CVE-2021-20233: Evne til å skrive data ut av bufferen på grunn av feil bufferstørrelsesberegning når du bruker anførselstegn. Ved beregning av størrelsen ble det antatt at det tar tre tegn å unnslippe et enkelt sitat, selv om det i virkeligheten tar fire.
Fuente: https://ubuntu.com