Mahirap ayusin ang mga kahinaan sa GRUB2 na nagbibigay-daan sa iyong i-bypass ang UEFI Secure Boot

Ang impormasyon ay isiniwalat tungkol sa 8 mga kahinaan sa GRUB2 bootloader, na nagbibigay-daan sa iyong i-bypass ang mekanismo ng UEFI Secure Boot at patakbuhin ang hindi na-verify na code, halimbawa, ipatupad ang malware na tumatakbo sa antas ng bootloader o kernel.

Alalahanin natin na sa karamihan ng mga distribusyon ng Linux, para sa na-verify na pag-boot sa UEFI Secure Boot mode, isang maliit na shim layer ang ginagamit, na digital na nilagdaan ng Microsoft. Bine-verify ng layer na ito ang GRUB2 gamit ang sarili nitong certificate, na nagpapahintulot sa mga developer ng pamamahagi na hindi magkaroon ng bawat kernel at GRUB update na na-certify ng Microsoft. Ang mga kahinaan sa GRUB2 ay nagbibigay-daan sa iyo na makamit ang pagpapatupad ng iyong code sa yugto pagkatapos ng matagumpay na pag-verify ng shim, ngunit bago i-load ang operating system, wedging sa chain of trust kapag aktibo ang Secure Boot mode at pagkakaroon ng ganap na kontrol sa karagdagang proseso ng boot, kabilang ang naglo-load ng isa pang OS, binabago ang operating system na mga bahagi ng system at i-bypass ang proteksyon ng Lockdown.

Tulad ng kahinaan sa BootHole noong nakaraang taon, ang pag-update ng bootloader ay hindi sapat upang harangan ang problema, dahil ang isang umaatake, anuman ang operating system na ginamit, ay maaaring gumamit ng bootable media na may luma, digitally signed, vulnerable na bersyon ng GRUB2 upang ikompromiso ang UEFI Secure Boot. Ang problema ay malulutas lamang sa pamamagitan ng pag-update sa listahan ng pagbawi ng sertipiko (dbx, UEFI Revocation List), ngunit sa kasong ito mawawala ang kakayahang gumamit ng lumang media sa pag-install sa Linux.

Sa mga system na may firmware na may na-update na listahan ng pagbawi ng certificate, tanging ang mga na-update na build ng mga distribusyon ng Linux ang maaaring i-load sa UEFI Secure Boot mode. Kakailanganin ng mga distribusyon na i-update ang mga installer, bootloader, kernel package, fwupd firmware at shim layer, na bumubuo ng mga bagong digital na lagda para sa kanila. Kakailanganin ng mga user na i-update ang mga larawan sa pag-install at iba pang bootable media, pati na rin ang pag-load ng listahan ng pagbawi ng certificate (dbx) sa UEFI firmware. Bago i-update ang dbx sa UEFI, nananatiling mahina ang system anuman ang pag-install ng mga update sa OS. Maaaring masuri ang katayuan ng mga kahinaan sa mga pahinang ito: Ubuntu, SUSE, RHEL, Debian.

Upang malutas ang mga problema na lumitaw kapag namamahagi ng mga binawi na sertipiko, sa hinaharap ay binalak na gamitin ang mekanismo ng SBAT (UEFI Secure Boot Advanced Targeting), ang suporta kung saan ipinatupad para sa GRUB2, shim at fwupd, at simula sa susunod na mga update ay magiging ginamit sa halip na ang functionality na ibinigay ng dbxtool package. Ang SBAT ay binuo nang magkasama sa Microsoft at nagsasangkot ng pagdaragdag ng bagong metadata sa mga executable na file ng mga bahagi ng UEFI, na kinabibilangan ng impormasyon tungkol sa tagagawa, produkto, bahagi at bersyon. Ang tinukoy na metadata ay na-certify gamit ang isang digital na lagda at maaari ding isama sa mga listahan ng pinapayagan o ipinagbabawal na mga bahagi para sa UEFI Secure Boot. Sa gayon, papayagan ka ng SBAT na manipulahin ang mga numero ng bersyon ng bahagi sa panahon ng pagbawi nang hindi kinakailangang muling buuin ang mga susi para sa Secure Boot at nang hindi bumubuo ng mga bagong lagda para sa kernel, shim, grub2 at fwupd.

Natukoy na mga kahinaan:

  • CVE-2020-14372 – Gamit ang acpi command sa GRUB2, ang isang privileged user sa local system ay makakapag-load ng mga binagong ACPI table sa pamamagitan ng paglalagay ng SSDT (Secondary System Description Table) sa /boot/efi directory at pagbabago ng mga setting sa grub.cfg. Bagama't aktibo ang Secure Boot mode, ang iminungkahing SSDT ay isasagawa ng kernel at maaaring gamitin upang hindi paganahin ang proteksyon ng LockDown na humaharang sa UEFI Secure Boot bypass path. Bilang resulta, makakamit ng isang attacker ang paglo-load ng kanyang kernel module o pagpapatakbo ng code sa pamamagitan ng mekanismo ng kexec, nang hindi sinusuri ang digital signature.
  • Ang CVE-2020-25632 ay isang use-after-free memory access sa pagpapatupad ng rmmod command, na nangyayari kapag sinubukang i-unload ang anumang module nang hindi isinasaalang-alang ang mga dependency na nauugnay dito. Hindi ibinubukod ng kahinaan ang paggawa ng pagsasamantala na maaaring humantong sa pagpapatupad ng code na lumalampas sa pag-verify ng Secure Boot.
  • CVE-2020-25647 Isang out-of-bounds na pagsusulat sa grub_usb_device_initialize() function na tinatawag kapag sinisimulan ang mga USB device. Ang problema ay maaaring pinagsamantalahan sa pamamagitan ng pagkonekta ng isang espesyal na inihandang USB device na gumagawa ng mga parameter na ang laki ay hindi tumutugma sa laki ng buffer na inilalaan para sa mga istruktura ng USB. Maaaring makamit ng isang attacker ang pagpapatupad ng code na hindi na-verify sa Secure Boot sa pamamagitan ng pagmamanipula ng mga USB device.
  • Ang CVE-2020-27749 ay isang buffer overflow sa grub_parser_split_cmdline() function, na maaaring sanhi ng pagtukoy ng mga variable na mas malaki sa 2 KB sa command line ng GRUB1. Ang kahinaan ay nagpapahintulot sa pagpapatupad ng code na laktawan ang Secure Boot.
  • CVE-2020-27779 – Ang utos ng cutmem ay nagbibigay-daan sa isang umaatake na mag-alis ng hanay ng mga address mula sa memorya upang i-bypass ang Secure Boot.
  • CVE-2021-3418 - Lumikha ng karagdagang vector ang mga pagbabago sa shim_lock para samantalahin ang kahinaan noong nakaraang taon na CVE-2020-15705. Sa pamamagitan ng pag-install ng certificate na ginamit para lagdaan ang GRUB2 sa dbx, pinahintulutan ng GRUB2 na direktang ma-load ang anumang kernel nang hindi bini-verify ang lagda.
  • CVE-2021-20225 - Posibilidad ng pagsulat ng out-of-bounds na data kapag nagpapatakbo ng mga command na may napakalaking bilang ng mga opsyon.
  • CVE-2021-20233 - Posibilidad ng pagsulat ng data sa labas ng mga hangganan dahil sa maling pagkalkula ng laki ng buffer kapag gumagamit ng mga panipi. Kapag kinakalkula ang laki, ipinapalagay na tatlong character ang kinakailangan upang makatakas sa isang solong quote, kung sa katunayan apat ang kinakailangan.

Pinagmulan: opennet.ru

Magdagdag ng komento