Ynformaasje is iepenbiere oer twa kwetsberens yn 'e GRUB2-bootloader, wat kin liede ta koade-útfiering by it brûken fan spesjaal ûntworpen lettertypen en it ferwurkjen fan bepaalde Unicode-sekwinsjes. Kwetsberheden kinne brûkt wurde om it UEFI Secure Boot ferifiearre bootmeganisme te omgean.
Identifisearre kwetsberens:
- CVE-2022-2601 - In bufferoerstream yn 'e funksje grub_font_construct_glyph() by it ferwurkjen fan spesjaal ûntwurpen lettertypen yn it pf2-formaat, wat bart troch in ferkearde berekkening fan 'e parameter max_glyph_size en de tawizing fan in ûnthâldgebiet dat fansels lytser is as nedich om plak foar de glyphs.
- CVE-2022-3775 In skriuw bûten de grinzen komt foar by it werjaan fan guon Unicode-sekwinsjes yn in spesjaal stylearre lettertype. It probleem is yn 'e lettertypeferwurkingskoade en wurdt feroarsake troch in gebrek oan goede kontrôles om te soargjen dat de breedte en hichte fan' e glyph oerienkomt mei de grutte fan 'e beskikbere bitmap. In oanfaller kin de ynfier op sa'n manier meitsje dat de sturt fan 'e gegevens oan 'e bûtenkant fan 'e tawiisde buffer skreaun wurdt. It wurdt opmurken dat nettsjinsteande de kompleksiteit fan it eksploitearjen fan 'e kwetsberens, it bringen fan it probleem nei koade-útfiering is net útsletten.
De fix is publisearre as in patch. De status fan it eliminearjen fan kwetsberens yn distribúsjes kin wurde beoardiele op dizze siden: Ubuntu, SUSE, RHEL, Fedora, Debian. Om problemen yn GRUB2 te reparearjen, is it net genôch om allinich it pakket te aktualisearjen; jo moatte ek nije ynterne digitale hantekeningen generearje en ynstallearders, bootloaders, kernelpakketten, fwupd-firmware en shim-laach bywurkje.
De measte Linux-distribúsjes brûke in lyts shim-laach digitaal ûndertekene troch Microsoft foar ferifiearre opstarten yn UEFI Secure Boot-modus. Dizze laach ferifiearret GRUB2 mei in eigen sertifikaat, wêrtroch distribúsjeûntwikkelders net elke kernel en GRUB-fernijing kinne hawwe sertifisearre troch Microsoft. Kwetsberheden yn GRUB2 kinne jo berikke de útfiering fan jo koade op it poadium nei suksesfolle shim ferifikaasje, mar foardat it laden fan it bestjoeringssysteem, wedging yn 'e keatling fan fertrouwen as Secure Boot modus is aktyf en it krijen fan folsleine kontrôle oer de fierdere boot proses, ynklusyf lade in oar OS, wizigjen bestjoeringssysteem komponinten systeem en bypass Lockdown beskerming.
Om de kwetsberens te blokkearjen sûnder de digitale hantekening yn te lûken, kinne distribúsjes it SBAT (UEFI Secure Boot Advanced Targeting) meganisme brûke, dat wurdt stipe foar GRUB2, shim en fwupd yn de meast populêre Linux-distribúsjes. SBAT is ûntwikkele tegearre mei Microsoft en omfettet it tafoegjen fan ekstra metadata oan 'e útfierbere bestannen fan UEFI-komponinten, dy't ynformaasje omfettet oer de fabrikant, produkt, komponint en ferzje. De opjûne metadata is sertifisearre mei in digitale hantekening en kinne apart wurde opnommen yn 'e listen fan tastiene of ferbeane komponinten foar UEFI Secure Boot.
SBAT lit jo it gebrûk fan digitale hantekeningen foar yndividuele ferzjenûmers fan komponinten blokkearje sûnder kaaien foar Secure Boot yn te lûken. Blokkearjen fan kwetsberens fia SBAT fereasket net it gebrûk fan in UEFI-sertifikaat weromlûkingslist (dbx), mar wurdt útfierd op it nivo fan it ferfangen fan de ynterne kaai om hantekeningen te generearjen en GRUB2, shim en oare bootartefakten te aktualisearjen levere troch distribúsjes. Foar de yntroduksje fan SBAT wie it bywurkjen fan de sertifikaat weromlûkingslist (dbx, UEFI Revocation List) in betingst foar it folslein blokkearjen fan de kwetsberens, om't in oanfaller, nettsjinsteande it brûkte bestjoeringssysteem, bootbere media brûke koe mei in âlde kwetsbere ferzje fan GRUB2, sertifisearre troch in digitale hantekening, om UEFI Secure Boot te kompromittearjen.
Boarne: opennet.ru