Nakakita sila ng dalawang kahinaan sa GRUB2

Ang mga detalye ng dalawang kahinaan sa GRUB2 boot loader ay isiniwalat na pmaaaring humantong sa pagpapatupad ng code kapag gumagamit ng mga espesyal na idinisenyong font at humahawak ng ilang partikular na pagkakasunud-sunod ng Unicode.

Nabanggit na ang mga vulnerabilities na nakita aye ay maaaring gamitin upang i-bypass ang UEFI Secure Boot verified boot mechanism. Ang mga kahinaan sa GRUB2 ay nagbibigay-daan sa code na maisakatuparan sa yugto pagkatapos ng matagumpay na pag-verify ng shim, ngunit bago ma-load ang operating system, sinira ang chain of trust gamit ang Secure Boot mode na aktibo at magkaroon ng ganap na kontrol sa proseso ng post-boot, hal. Halimbawa, upang magsimula ng isa pang operating system, baguhin ang mga bahagi ng operating system, at i-bypass ang proteksyon ng lock.

Tungkol sa mga natukoy na kahinaan, ang mga sumusunod ay nabanggit:

• CVE-2022-2601: isang buffer overflow sa grub_font_construct_glyph() function kapag nagpoproseso ng mga espesyal na ginawang font sa pf2 na format, na nangyayari dahil sa maling pagkalkula ng max_glyph_size na parameter at paglalaan ng isang lugar ng memorya na halatang mas maliit kaysa sa kinakailangan para maglagay ng mga glyph.
• CVE-2022-3775: Out of bounds writing kapag nag-render ng ilang Unicode string sa isang custom na font. Ang problema ay naroroon sa code ng paghawak ng font at sanhi ng kakulangan ng mga wastong kontrol upang matiyak na ang lapad at taas ng glyph ay tumutugma sa magagamit na laki ng bitmap. Ang isang attacker ay maaaring mag-harvest ng input sa paraang maging sanhi ng isang queue ng data na maisulat sa inilaan na buffer. Nabanggit na sa kabila ng pagiging kumplikado ng pagsasamantala sa kahinaan, ang paglalantad ng problema sa pagpapatupad ng code ay hindi ibinubukod.

Ang buong pagpapagaan laban sa lahat ng CVE ay mangangailangan ng mga pag-aayos na na-update gamit ang pinakabagong SBAT (Secure Boot Advanced Targeting) at data na ibinigay ng mga distribusyon at vendor.
Sa pagkakataong ito ang UEFI revocation list (dbx) ay hindi na gagamitin at ang pagpapawalang-bisa sa mga nasira
ang mga artifact ay gagawin lamang gamit ang SBAT. Para sa impormasyon kung paano mag-aplay ang
pinakabagong mga pagbawi ng SBAT, tingnan ang mokutil(1). Ang mga pag-aayos ng vendor ay maaaring tahasang payagan ang pag-boot ng mga mas lumang kilalang boot artifact.

Maa-update ang GRUB2, shim, at iba pang boot artifact mula sa lahat ng apektadong vendor. ito ay magagamit kapag ang embargo ay inalis o ilang oras pagkatapos.

Binanggit iyon karamihan sa mga distribusyon ng linux ay gumagamit ng maliit na patch layer, digital na nilagdaan ng Microsoft, para sa na-verify na boot sa UEFI Secure Boot mode. Ang layer na ito ay nagpapatunay sa GRUB2 na may sariling sertipiko, na nagpapahintulot sa mga developer ng pamamahagi na hindi ma-certify ang bawat kernel at GRUB update sa Microsoft.

Upang harangan ang kahinaan nang hindi binabawi ang digital signature, mga pamamahagi maaaring gumamit ng mekanismo ng SBAT (UEFI Secure Boot Advanced Targeting), na sinusuportahan ng GRUB2, shim, at fwupd sa pinakasikat na mga distribusyon ng Linux.

Ang SBAT ay binuo sa pakikipagtulungan sa Microsoft at nagsasangkot ng pagdaragdag ng karagdagang metadata sa UEFI component executable file, kabilang ang impormasyon ng manufacturer, produkto, bahagi, at bersyon. Ang tinukoy na metadata ay digital na nilagdaan at maaaring isama sa hiwalay na pinapayagan o ipinagbabawal na mga listahan ng bahagi para sa UEFI Secure Boot.

Pinapayagan ng SBAT ang pagharang sa paggamit ng isang digital na lagda para sa indibidwal na mga numero ng bersyon ng component nang hindi kailangang bawiin ang mga key para sa Secure Boot. Ang pagharang sa mga kahinaan sa pamamagitan ng SBAT ay hindi nangangailangan ng paggamit ng UEFI CRL (dbx), ngunit sa halip ay ginagawa sa panloob na antas ng pagpapalit ng susi upang bumuo ng mga lagda at i-update ang GRUB2, shim, at iba pang mga boot artifact na ibinigay ng mga distribusyon.

Bago ang pagpapakilala ng SBAT, ang pag-update sa listahan ng pagbawi ng certificate (dbx, UEFI Revocation List) ay isang kinakailangan upang ganap na harangan ang kahinaan, dahil ang isang attacker, anuman ang operating system na ginamit, ay maaaring gumamit ng bootable na media. na may mas lumang bersyon Ang GRUB2 ay na-certify ng isang digital signature para ikompromiso ang UEFI Secure Boot.

Sa wakas Ito ay nagkakahalaga ng pagbanggit na ang pag-aayos ay inilabas bilang isang patch., upang ayusin ang mga problema sa GRUB2, hindi sapat na i-update ang package, kakailanganin mo ring lumikha ng mga bagong panloob na digital signature at i-update ang mga installer, bootloader, kernel packages, fwupd-firmware at shim-layer.

Maaaring masuri ang katayuan ng pagreremedia ng kahinaan sa mga pamamahagi sa mga pahinang ito: Ubuntu, SUSE, RHEL, Fedora y Debian.

Maaari mong suriin ang higit pa tungkol dito sa sumusunod na link.