Moeilik om te herstel kwesbaarhede in GRUB2 wat jou toelaat om UEFI Secure Boot te omseil

Inligting is bekend gemaak oor 8 kwesbaarhede in die GRUB2 selflaaiprogram, wat jou toelaat om die UEFI Secure Boot meganisme te omseil en ongeverifieerde kode te laat loop, byvoorbeeld, implementeer wanware wat op die selflaailaaier of kernvlak loop.

Laat ons onthou dat in die meeste Linux-verspreidings, vir geverifieerde selflaai in UEFI Secure Boot-modus, 'n klein shim-laag gebruik word, digitaal onderteken deur Microsoft. Hierdie laag verifieer GRUB2 met sy eie sertifikaat, wat verspreidingsontwikkelaars toelaat om nie elke kern- en GRUB-opdatering deur Microsoft te laat sertifiseer nie. Kwesbaarhede in GRUB2 stel jou in staat om die uitvoering van jou kode te bereik op die stadium na suksesvolle shim-verifikasie, maar voor die laai van die bedryfstelsel, in die ketting van vertroue inwig wanneer Secure Boot-modus aktief is en volle beheer oor die verdere selflaaiproses te verkry, insluitend laai 'n ander bedryfstelsel, wysiging van bedryfstelselkomponentestelsel en omseil Lockdown-beskerming.

Soos met verlede jaar se BootHole-kwesbaarheid, is die opdatering van die selflaaiprogram nie genoeg om die probleem te blokkeer nie, aangesien 'n aanvaller, ongeag die bedryfstelsel wat gebruik word, selflaaibare media met 'n ou, digitaal ondertekende, kwesbare weergawe van GRUB2 kan gebruik om UEFI Secure Boot in die gedrang te bring. Die probleem kan slegs opgelos word deur die sertifikaatherroepingslys (dbx, UEFI-herroepingslys) op te dateer, maar in hierdie geval sal die vermoë om ou installasiemedia met Linux te gebruik, verlore gaan.

Op stelsels met firmware wat 'n bygewerkte sertifikaatherroepingslys het, kan slegs opgedateerde weergawes van Linux-verspreidings in UEFI Secure Boot-modus gelaai word. Verspreidings sal installeerders, selflaailaaiers, kernpakkette, fwupd-firmware en shim-laag moet opdateer, wat nuwe digitale handtekeninge vir hulle genereer. Daar sal van gebruikers vereis word om installasiebeelde en ander selflaaibare media op te dateer, asook 'n sertifikaatherroepingslys (dbx) in die UEFI-firmware te laai. Voordat dbx na UEFI opgedateer word, bly die stelsel kwesbaar, ongeag die installering van opdaterings in die bedryfstelsel. Die status van kwesbaarhede kan op hierdie bladsye beoordeel word: Ubuntu, SUSE, RHEL, Debian.

Om probleme op te los wat ontstaan ​​wanneer herroepe sertifikate versprei word, word daar in die toekoms beplan om die SBAT (UEFI Secure Boot Advanced Targeting)-meganisme te gebruik, waarvoor ondersteuning vir GRUB2, shim en fwupd geïmplementeer is, en vanaf die volgende opdaterings sal wees. gebruik in plaas van die funksionaliteit wat deur die dbxtool-pakket verskaf word. SBAT is saam met Microsoft ontwikkel en behels die toevoeging van nuwe metadata tot die uitvoerbare lêers van UEFI-komponente, wat inligting oor die vervaardiger, produk, komponent en weergawe insluit. Die gespesifiseerde metadata is gesertifiseer met 'n digitale handtekening en kan addisioneel ingesluit word in die lyste van toegelate of verbode komponente vir UEFI Secure Boot. SBAT sal jou dus toelaat om komponentweergawenommers tydens herroeping te manipuleer sonder dat dit nodig is om sleutels vir Secure Boot te hergenereer en sonder om nuwe handtekeninge vir die kern, shim, grub2 en fwupd te genereer.

Geïdentifiseerde kwesbaarhede:

  • CVE-2020-14372 – Deur die acpi-opdrag in GRUB2 te gebruik, kan 'n bevoorregte gebruiker op die plaaslike stelsel gewysigde ACPI-tabelle laai deur 'n SSDT (Secondary System Description Table) in die /boot/efi-gids te plaas en instellings in grub.cfg te verander. Alhoewel Secure Boot-modus aktief is, sal die voorgestelde SSDT deur die kern uitgevoer word en kan dit gebruik word om LockDown-beskerming te deaktiveer wat UEFI Secure Boot-omleidingspaaie blokkeer. As gevolg hiervan kan 'n aanvaller die laai van sy kernmodule of lopende kode deur die kexec-meganisme bewerkstellig, sonder om die digitale handtekening na te gaan.
  • CVE-2020-25632 is 'n gebruik-na-vrye geheuetoegang in die implementering van die rmmod-opdrag, wat plaasvind wanneer 'n poging aangewend word om enige module af te laai sonder om die afhanklikhede wat daarmee geassosieer word in ag te neem. Die kwesbaarheid sluit nie die skep van 'n uitbuiting uit wat kan lei tot die uitvoering van kode wat Secure Boot-verifikasie omseil nie.
  • CVE-2020-25647 'n Buitegrens-skryf in die grub_usb_device_initialize()-funksie wat genoem word wanneer USB-toestelle geïnisialiseer word. Die probleem kan uitgebuit word deur 'n spesiaal voorbereide USB-toestel te koppel wat parameters produseer waarvan die grootte nie ooreenstem met die grootte van die buffer wat vir USB-strukture toegewys is nie. 'n Aanvaller kan uitvoering kry van kode wat nie in Secure Boot geverifieer is nie deur USB-toestelle te manipuleer.
  • CVE-2020-27749 is 'n bufferoorloop in die grub_parser_split_cmdline()-funksie, wat veroorsaak kan word deur veranderlikes groter as 2 KB op die GRUB1-opdragreël te spesifiseer. Die kwesbaarheid laat die uitvoering van kode toe om Secure Boot te omseil.
  • CVE-2020-27779 – Die cutmem-opdrag laat 'n aanvaller toe om 'n reeks adresse uit die geheue te verwyder om Veilige opstart te omseil.
  • CVE-2021-3418 - Veranderinge aan shim_lock het 'n bykomende vektor geskep om verlede jaar se kwesbaarheid CVE-2020-15705 te ontgin. Deur die sertifikaat wat gebruik is om GRUB2 te onderteken in dbx te installeer, het GRUB2 toegelaat dat enige kern direk gelaai word sonder om die handtekening te verifieer.
  • CVE-2021-20225 - Moontlikheid om buite-grens data te skryf wanneer opdragte uitgevoer word met 'n baie groot aantal opsies.
  • CVE-2021-20233 - Moontlikheid om data buite perke te skryf as gevolg van verkeerde buffergrootte-berekening wanneer aanhalingstekens gebruik word. By die berekening van die grootte is aangeneem dat drie karakters benodig word om 'n enkele aanhaling te ontsnap, terwyl dit in werklikheid vier vereis word.

Bron: opennet.ru

Voeg 'n opmerking