To sårbarheter i GRUB2 som lar deg omgå UEFI Secure Boot-beskyttelse

Det er avslørt informasjon om to sårbarheter i GRUB2-oppstartslasteren, som kan føre til kodekjøring ved bruk av spesialdesignede fonter og behandling av visse Unicode-sekvenser. Sårbarheter kan brukes til å omgå den UEFI Secure Boot-verifiserte oppstartsmekanismen.

Identifiserte sårbarheter:

  • CVE-2022-2601 - En bufferoverflyt i grub_font_construct_glyph()-funksjonen ved behandling av spesialdesignede fonter i pf2-formatet, som oppstår på grunn av feil beregning av parameteren max_glyph_size og allokering av et minneområde som åpenbart er mindre enn nødvendig for å imøtekomme glyfer.
  • CVE-2022-3775 En out-of-bounds-skriving oppstår når noen Unicode-sekvenser gjengis i en spesialstilt skrift. Problemet ligger i skriftbehandlingskoden og er forårsaket av mangel på riktige kontroller for å sikre at bredden og høyden på glyfen samsvarer med størrelsen på den tilgjengelige punktgrafikken. En angriper kan lage inndataene på en slik måte at den fører til at halen av dataene blir skrevet til utsiden av den tildelte bufferen. Det bemerkes at til tross for kompleksiteten ved å utnytte sårbarheten, er det ikke utelukket å bringe problemet til kodekjøring.

Reparasjonen har blitt publisert som en oppdatering. Status for eliminering av sårbarheter i distribusjoner kan vurderes på disse sidene: Ubuntu, SUSE, RHEL, Fedora, Debian. For å fikse problemer i GRUB2 er det ikke nok bare å oppdatere pakken; du må også generere nye interne digitale signaturer og oppdatere installasjonsprogrammer, oppstartslastere, kjernepakker, fwupd-fastvare og shim-lag.

De fleste Linux-distribusjoner bruker et lite shim-lag digitalt signert av Microsoft for bekreftet oppstart i UEFI Secure Boot-modus. 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.

For å blokkere sårbarheten uten å oppheve den digitale signaturen, kan distribusjoner bruke SBAT (UEFI Secure Boot Advanced Targeting)-mekanismen, som støttes for GRUB2, shim og fwupd i de fleste populære Linux-distribusjoner. SBAT ble utviklet i samarbeid med Microsoft og innebærer å legge til ytterligere 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 inkluderes separat i listene over tillatte eller forbudte komponenter for UEFI Secure Boot.

SBAT lar deg blokkere bruken av digitale signaturer for individuelle komponentversjonsnumre uten å måtte tilbakekalle nøkler for sikker oppstart. Blokkering av sårbarheter via SBAT krever ikke bruk av en UEFI-sertifikatopphevelsesliste (dbx), men utføres på nivået for å 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 sertifikatopphevelseslisten (dbx, UEFI Revocation List) en forutsetning for fullstendig blokkering av sårbarheten, siden en angriper, uavhengig av hvilket operativsystem som brukes, kunne bruke oppstartbare medier med en gammel sårbar versjon av GRUB2, sertifisert av en digital signatur, for å kompromittere UEFI Secure Boot .

Kilde: opennet.ru

Legg til en kommentar