Si Matthew Garrett, isang kilalang developer ng kernel Linux, na minsang nakatanggap ng parangal mula sa Free Software Foundation para sa kanyang kontribusyon sa pagbuo ng libreng software, ay nagsalita tungkol sa esensya ng mekanismo ng SBAT (Secure Boot Advanced Targeting), na nilikha upang harangan ang mga kahinaan sa bootloader nang hindi binabawi ang digital signature, pati na rin ang papel nito sa kamakailang insidente sa pag-update para sa Windows, na naging dahilan upang huminto sa paglo-load ang ilang distribusyon Linux, naka-install nang parallel sa Windows sa mga system na may naka-enable na UEFI Secure Boot. Sa madaling salita, parehong ang Microsoft, na hindi lubusang sumubok sa update at naglapat nito sa mga system na hindi dapat nito ginawa, at ang mga developer ng ilang distribution ang dapat sisihin. Linux, na hindi nag-update ng GRUB bootloader at SBAT generation number nang matuklasan ang mga kahinaan sa GRUB.
Nasa ibaba ang pagsasalin ng tala ni Garrett:
Noong binuo ang detalye ng UEFI Secure Boot, lahat ng kalahok nito ay, sabihin natin, medyo walang muwang. Ang pangunahing modelo ng seguridad ng Secure Boot ay ang lahat ng code na tumatakbo sa isang privileged environment sa kernel level ay dapat na ma-verify bago ang execution - ang firmware ay nagpapatunay sa bootloader, ang bootloader ay nagve-verify sa kernel, ang kernel ay nag-verify ng anumang karagdagang kernel code na na-load sa runtime, at ngayon ay mayroon na kaming pinagkakatiwalaang kapaligiran upang magpataw ng anumang iba pang patakaran sa seguridad na gusto namin. Malinaw na ang mga tao ay maaaring magkamali, ngunit ang detalye ay nagbigay ng paraan upang bawiin ang mga nilagdaang bahagi na napag-alamang hindi mapagkakatiwalaan: magdagdag lang ng hash ng hindi pinagkakatiwalaang code sa isang variable, at pagkatapos ay tumangging mag-load ng anuman gamit ang hash na iyon, kahit na ito ay nilagdaan. na may pinagkakatiwalaang susi.
Sa kasamaang palad, lumalabas na ang problema ay nasa iskala. Ang bawat distribusyon Linux, na tumatakbo sa loob ng Secure Boot ecosystem, ay bumubuo ng sarili nitong bootloader binaries, bawat isa ay may sarili nitong hash. Kung may matuklasan na kahinaan sa source code ng naturang bootloader, maraming iba't ibang binaries ang kailangang i-recall. Limitado ang espasyo ng memorya para sa pag-iimbak ng isang variable na naglalaman ng lahat ng mga hash na ito. Wala talagang sapat na espasyo para magdagdag ng bagong set ng mga hash sa tuwing ang GRUB (isang bootloader na orihinal na isinulat noong panahon bago ang Secure Boot, na may ilang magkakahiwalay na .img parser at isang font parser) ay matuklasan na may ibang mekanismo para sa isang attacker na magpatupad ng arbitrary code, kaya kinailangan ng isa pang solusyon.
Ang solusyon na iyon ay SBAT. Ang pangkalahatang konsepto ng SBAT ay medyo simple. Ang bawat kritikal na bahagi sa boot chain ay nagdedeklara ng henerasyon ng seguridad na kasama sa nilagdaang binary. Kapag ang isang kahinaan ay natuklasan at naayos, ang henerasyong ito ay tumataas. Maaaring maglabas ng update na tumutukoy sa minimum na henerasyon - titingnan ng mga bahagi ng boot ang susunod na item sa chain, ihambing ang pangalan at numero ng henerasyon nito sa mga nakaimbak sa variable ng firmware, at magpapasya kung isasagawa ito o hindi batay doon . Sa halip na bawiin ang isang malaking bilang ng mga indibidwal na hash, maaari kang mag-isyu ng isang update na nagsasabing, "Anumang bersyon ng GRUB na may henerasyon ng seguridad sa ibaba ng numerong ito ay itinuturing na hindi pinagkakatiwalaan."
Bakit bigla itong naging mahalaga? Ang SBAT ay binuo nang sama-sama ng komunidad. Linux at nagpasya ang Microsoft at Microsoft na maglabas ng update para sa Windows, na nagsasabi sa mga sistema na huwag magtiwala sa mga bersyon ng GRUB na may henerasyon ng seguridad na mas mababa sa isang tiyak na antas. Ginawa ito dahil ang mga bersyong GRUB na ito ay may mga tunay na kahinaan sa seguridad na nagpapahintulot sa mga umaatake na sirain ang secure boot chain. Windows, at nakakita na tayo ng mga totoong halimbawa ng malware na gustong gawin ito (sinamantala ng Black Lotus ang isang kahinaan sa bootloader Windows, ngunit ang kahinaan ng GRUB ay kasing epektibo rin). Mula sa isang purong pananaw ng seguridad, ito ay isang ganap na lehitimong hangarin.
Ngayon, tungkol sa mensaheng "May nangyaring seryosong mali" at ang kawalan ng kakayahang mag-boot bilang resulta ng update na ito, si Shim ang naglalabas nito, hindi ang ilang code mula sa Microsoft. Isinasaalang-alang ng Shim ang mga SBAT update, at upang hindi lumabag sa mga prinsipyo ng seguridad na pinagtibay ng ibang mga bootloader sa system, at bagama't naglabas ang Microsoft ng SBAT update, ang bootloader ang may pananagutan. Linux Dahil dito, tumatangging ilunsad nito ang mga mas lumang bersyon ng GRUB. Gumagana naman ang lahat ayon sa nararapat.
Ang problemang naranasan ng mga tao ay ang maraming distribusyon Linux hindi naglabas ng mga bersyon ng GRUB na may mas bagong henerasyon ng seguridad, at samakatuwid ang mga bersyong ito ng GRUB ay itinuturing na hindi ligtas (mahalagang tandaan na ang GRUB ay nilagdaan mismo ng mga distribusyon, hindi ng Microsoft, kaya walang panlabas na ipinakilalang lag dito). Ayon sa plano ng Microsoft, ang update Windows Dapat sana ay ilapat lamang ng update ang SBAT update sa mga sistemang tumatakbo lamang Windows, at anumang dual-boot installation ay mananatiling mahina laban sa atake hanggang sa ma-update ng naka-install na distribution ang GRUB at ang SBAT generation. Sa kasamaang palad, gaya ng malinaw ngayon, hindi ito gumana ayon sa nilalayon, at kahit papaano ay inilapat ng ilang dual-boot system ang update, at tumanggi ang Shim ng distribution na i-load ang GRUB.
Ano ang konklusyon? Ayaw ng Microsoft (sa mga halatang dahilan) Windows maaaring atakihin gamit ang isang mahinang bersyon ng GRUB, na maaaring linlangin sa pagpapatupad ng arbitraryong code at pagkatapos ay pag-inject ng bootkit sa kernel Windows habang nagbo-boot. Ginawa ito ng Microsoft sa pamamagitan ng paglabas ng isang update Windows, na nag-update sa variable na SBAT upang ipahiwatig na ang mga mahinang bersyon ng GRUB ay hindi dapat i-boot sa mga sistemang ito. Binasa ng first-stage bootloader na ibinigay ng distribution ng Shim ang variable na ito, binasa ang SBAT partition mula sa naka-install na kopya ng GRUB, napagtanto na magkasalungat ang mga ito, at tumangging i-load ang GRUB gamit ang mensaheng "May nangyaring seryosong mali." Ang update na ito ay hindi nilayong ilapat sa mga dual-boot system, ngunit nailapat pa rin ito.
Sa pangkalahatan:
1) Inilapat ng Microsoft ang update sa mga system kung saan hindi ito dapat ilapat.
2) Ilang distribusyon Linux hindi na-update ang GRUB bootloader at ang SBAT security generation nang matuklasan ang mga kahinaan sa GRUB.
Bilang resulta, ang ilang mga tao ay hindi ma-boot ang kanilang mga system. Sa tingin ko maraming tao ang dapat sisihin dito. Ang Microsoft ay dapat na gumawa ng higit pang pagsubok upang matiyak na ang mga dual boot installation ay maaaring tumpak na matukoy. Ngunit ang mga distribusyon na nagsusuplay ng mga naka-sign na bootloader ay kailangang tiyakin na ina-update nila ang mga ito at ina-update ang henerasyon ng seguridad upang tumugma, dahil kung hindi man ay nagbibigay sila ng vector ng pag-atake na magagamit upang i-hack ang iba pang mga operating system, at iyon ay isang uri ng paglabag sa panlipunang kontrata sa paligid nito. lahat.
Sa kasamaang palad, ang mga biktima dito ay pangunahing mga end user na nahaharap sa katotohanan na ang system ay biglang tumanggi na i-load ang OS na gusto nilang i-load. Hindi ito dapat mangyari. Sa palagay ko ay hindi magbubunga ng magandang resulta ang pagtatanong sa mga end user kung gusto nila ng mga update sa Secure Boot, at bagama't malabo kong isipin na ang UEFI Secure Boot ay hindi isang bagay na nakikinabang sa karamihan ng mga end user, ito rin ang bagay na ginagawa mo Hindi ko gustong malaman pagkatapos ng mga insidenteng tulad nito, kaya naman nakikiramay ako na ito ay pinagana bilang default, kaya sinusuportahan ko ang pag-enable nito bilang default, at ibahagi ang pagpipilian ng Microsoft, maliban sa hindi magandang pagtatangka na maiwasan ang pag-update sa mga dual boot system.
Sa anumang kaso, ako ay lubos na kasangkot sa pagpapatupad ng mekanismong ito para sa Linux noong 2012 at isinulat ang unang prototype ng Shim (na ngayon ay isang mas mahusay na bootloader, sinusuportahan ng mas malawak na hanay ng mga tao, at hindi ko pa nagagalaw sa loob ng ilang taon), kaya kung gusto mong sisihin ang isang tao, huwag mag-atubiling sisihin ako. Ito ay isang bagay na hindi dapat nangyari, at maliban kung ikaw ay Microsoft o isang distro Linux, kung gayon hindi mo kasalanan. Humihingi ako ng paumanhin.
Pinagmulan: opennet.ru
