Informasjon har blitt avslørt om 8 sårbarheter i GRUB2-oppstartslasteren, som lar deg omgå UEFI Secure Boot-mekanismen og kjøre ubekreftet kode, for eksempel implementere skadelig programvare som kjører på oppstartslaster- eller kjernenivå.
La oss huske at i de fleste Linux-distribusjoner, for bekreftet oppstart i UEFI Secure Boot-modus, brukes et lite shim-lag, digitalt signert av Microsoft. Dette laget verifiserer GRUB2 med sitt eget sertifikat, som lar distribusjonsutviklere ikke ha hver kjerne- og GRUB-oppdatering sertifisert av Microsoft. Sårbarheter i GRUB2 lar deg oppnå kjøringen av koden din på stadiet etter vellykket shim-verifisering, men før du laster operativsystemet, kiler inn i tillitskjeden når Secure Boot-modus er aktiv og får full kontroll over den videre oppstartsprosessen, inkludert laste inn et annet OS, endre operativsystemets komponenter og omgå låsebeskyttelse.
Som med fjorårets BootHole-sårbarhet, er oppdatering av oppstartslasteren ikke nok til å blokkere problemet, siden en angriper, uavhengig av operativsystemet som brukes, kan bruke oppstartbare medier med en gammel, digitalt signert, sårbar versjon av GRUB2 for å kompromittere UEFI Secure Boot. Problemet kan bare løses ved å oppdatere sertifikatopphevelseslisten (dbx, UEFI Revocation List), men i dette tilfellet vil muligheten til å bruke gamle installasjonsmedier med Linux gå tapt.
På systemer med fastvare som har en oppdatert sertifikatopphevelsesliste, kan bare oppdaterte bygg av Linux-distribusjoner lastes i UEFI Secure Boot-modus. Distribusjoner må oppdatere installatører, oppstartslastere, kjernepakker, fwupd-fastvare og shim-lag, og generere nye digitale signaturer for dem. Brukere vil bli pålagt å oppdatere installasjonsbilder og andre oppstartbare medier, samt laste inn en sertifikatopphevelsesliste (dbx) i UEFI-fastvaren. Før du oppdaterer dbx til UEFI, forblir systemet sårbart uavhengig av installasjon av oppdateringer i operativsystemet. Status for sårbarheter kan vurderes på disse sidene: Ubuntu, SUSE, RHEL, Debian.
For å løse problemer som oppstår ved distribusjon av tilbakekalte sertifikater, planlegges det i fremtiden å bruke SBAT (UEFI Secure Boot Advanced Targeting)-mekanismen, støtte for denne er implementert for GRUB2, shim og fwupd, og fra og med de neste oppdateringene vil bli implementert. brukt i stedet for funksjonaliteten som tilbys av dbxtool-pakken. SBAT ble utviklet i samarbeid med Microsoft og innebærer å legge til nye metadata til de kjørbare filene til UEFI-komponenter, som inkluderer informasjon om produsent, produkt, komponent og versjon. De angitte metadataene er sertifisert med en digital signatur og kan i tillegg inkluderes i listene over tillatte eller forbudte komponenter for UEFI Secure Boot. Dermed vil SBAT tillate deg å manipulere komponentversjonsnumre under tilbakekalling uten å måtte regenerere nøkler for sikker oppstart og uten å generere nye signaturer for kjernen, shim, grub2 og fwupd.
Identifiserte sårbarheter:
- CVE-2020-14372 – Ved å bruke acpi-kommandoen i GRUB2, kan en privilegert bruker på det lokale systemet laste inn modifiserte ACPI-tabeller ved å plassere en SSDT (Secondary System Description Table) i /boot/efi-katalogen og endre innstillinger i grub.cfg. Selv om Secure Boot-modus er aktiv, vil den foreslåtte SSDT-en kjøres av kjernen og kan brukes til å deaktivere LockDown-beskyttelse som blokkerer UEFI Secure Boot-bypass-baner. Som et resultat kan en angriper oppnå lasting av kjernemodulen eller kjørekoden gjennom kexec-mekanismen, uten å sjekke den digitale signaturen.
- CVE-2020-25632 er en bruk-etter-fri minnetilgang i implementeringen av rmmod-kommandoen, som oppstår når det gjøres et forsøk på å laste ut en modul uten å ta hensyn til avhengighetene knyttet til den. Sikkerhetsproblemet utelukker ikke opprettelsen av en utnyttelse som kan føre til at kodekjøring omgår sikker oppstartsbekreftelse.
- CVE-2020-25647 En out-of-bounds-skriving i grub_usb_device_initialize()-funksjonen som kalles ved initialisering av USB-enheter. Problemet kan utnyttes ved å koble til en spesielt forberedt USB-enhet som produserer parametere hvis størrelse ikke samsvarer med størrelsen på bufferen som er tildelt for USB-strukturer. En angriper kan oppnå kjøring av kode som ikke er verifisert i Secure Boot ved å manipulere USB-enheter.
- CVE-2020-27749 er en bufferoverflyt i grub_parser_split_cmdline()-funksjonen, som kan forårsakes ved å spesifisere variabler større enn 2 KB på GRUB1-kommandolinjen. Sikkerhetsproblemet lar kodekjøring omgå sikker oppstart.
- CVE-2020-27779 – Cutmem-kommandoen 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 sårbarhet CVE-2020-15705. Ved å installere sertifikatet som ble brukt til å signere GRUB2 i dbx, tillot GRUB2 at enhver kjerne ble lastet direkte uten å verifisere signaturen.
- CVE-2021-20225 - Mulighet for å skrive data utenfor grensene når du kjører kommandoer med et veldig stort antall alternativer.
- CVE-2021-20233 - Mulighet for å skrive data utenfor grensene på grunn av feil bufferstørrelsesberegning ved bruk av anførselstegn. Ved beregning av størrelsen ble det antatt at tre tegn var nødvendig for å unnslippe et enkelt anførselstegn, mens det faktisk var nødvendig med fire.
Kilde: opennet.ru