Twee kwesbaarhede in GRUB2 wat jou toelaat om UEFI Secure Boot-beskerming te omseil

Inligting is bekend gemaak oor twee kwesbaarhede in die GRUB2 selflaaiprogram, wat kan lei tot kode-uitvoering wanneer spesiaal ontwerpte lettertipes gebruik word en sekere Unicode-reekse verwerk word. Kwesbaarhede kan gebruik word om die UEFI Secure Boot-geverifieerde selflaaimeganisme te omseil.

Geïdentifiseerde kwesbaarhede:

  • CVE-2022-2601 - 'n Bufferoorloop in die grub_font_construct_glyph()-funksie wanneer spesiaal ontwerpte lettertipes in die pf2-formaat verwerk word, wat plaasvind as gevolg van 'n verkeerde berekening van die max_glyph_size-parameter en die toekenning van 'n geheue-area wat natuurlik kleiner is as wat nodig is om akkommodeer die glyphs.
  • CVE-2022-3775 'n Buitegrens-skryf vind plaas wanneer sommige Unicode-reekse in 'n spesiaal-gestileerde lettertipe weergegee word. Die probleem is in die fontverwerkingskode en word veroorsaak deur 'n gebrek aan behoorlike kontrole om te verseker dat die breedte en hoogte van die glyph ooreenstem met die grootte van die beskikbare bitmap. 'n Aanvaller kan die invoer op so 'n manier maak dat die stert van die data na die buitekant van die toegewese buffer geskryf word. Daar word kennis geneem dat ten spyte van die kompleksiteit van die uitbuiting van die kwesbaarheid, is dit nie uitgesluit om die probleem na kode-uitvoering te bring nie.

Die regstelling is as 'n pleister gepubliseer. Die status van die uitskakeling van kwesbaarhede in verspreidings kan op hierdie bladsye beoordeel word: Ubuntu, SUSE, RHEL, Fedora, Debian. Om probleme in GRUB2 op te los, is dit nie genoeg om net die pakket op te dateer nie; jy sal ook nuwe interne digitale handtekeninge moet genereer en installeerders, selflaailaaiers, kernpakkette, fwupd-firmware en shim-laag moet opdateer.

Die meeste Linux-verspreidings gebruik 'n klein shim-laag, digitaal onderteken deur Microsoft, vir geverifieerde selflaai in UEFI Secure Boot-modus. Hierdie laag verifieer GRUB2 met sy eie sertifikaat, wat verspreidingsontwikkelaars toelaat om nie elke kern- en GRUB-opdatering met Microsoft te sertifiseer nie. Kwesbaarhede in GRUB2 stel jou in staat om jou kode uit te voer op die stadium na suksesvolle verifikasie van shim, maar voor die laai van die bedryfstelsel, in die ketting van vertroue inwig met die Secure Boot-modus aktief en volle beheer oor die verdere selflaaiproses te verkry, insluitend die selflaai van 'n ander OS, wysiging van bedryfstelsel komponente stelsel en omseil toesluitbeskerming.

Om die kwesbaarheid te blokkeer sonder om die digitale handtekening te herroep, kan verspreidings die SBAT (UEFI Secure Boot Advanced Targeting)-meganisme gebruik, wat vir GRUB2, shim en fwupd in die gewildste Linux-verspreidings ondersteun word. SBAT is saam met Microsoft ontwikkel en behels die toevoeging van bykomende 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 afsonderlik ingesluit word in die lyste van toegelate of verbode komponente vir UEFI Secure Boot.

SBAT laat jou toe om die gebruik van digitale handtekeninge vir individuele komponentweergawenommers te blokkeer sonder om sleutels vir Secure Boot te herroep. Blokkering van kwesbaarhede via SBAT vereis nie die gebruik van 'n UEFI-sertifikaatherroepingslys (dbx) nie, maar word uitgevoer op die vlak van die vervanging van die interne sleutel om handtekeninge te genereer en GRUB2, shim en ander selflaai-artefakte wat deur verspreidings verskaf word, op te dateer. Voor die bekendstelling van SBAT was die opdatering van die sertifikaatherroepingslys (dbx, UEFI-herroepingslys) 'n voorvereiste om die kwesbaarheid heeltemal te blokkeer, aangesien 'n aanvaller, ongeag die bedryfstelsel wat gebruik word, selflaaibare media met 'n ou kwesbare weergawe van GRUB2 kon gebruik, gesertifiseer deur 'n digitale handtekening, om UEFI Secure Boot in die gedrang te bring.

Bron: opennet.ru

Voeg 'n opmerking