Matthew Garrett, një zhvillues i njohur i bërthamës Linux, i cili ndonjëherë ka marrë çmime nga Fondi i Kodit të Lirë për kontributin e tij në zhvillimin e softuerit të lirë, shpjegoi thelbin e mekanizmit SBAT (Secure Boot Advanced Targeting), i krijuar për të bllokuar dobësitë në bootloader pa anulluar nënshkrimin digjital, si dhe rolin e tij në incidentin e fundit me përditësimin për Windows, i cili çoi në ndërprerjen e ngarkimit të disa distribucioneve Linux, të instaluara paralelisht me Windows në sisteme që kishin aktivizuar UEFI Secure Boot. Në përmbledhje, fajin e kanë si kompania Microsoft, e cila nuk e kishte testuar plotësisht përditësimin dhe e kishte aplikuar atë në sisteme ku nuk duhej aplikuar, ashtu si dhe zhvilluesit e disa distribucioneve Linux, të cilët nuk e kishin përditësuar bootloader-in GRUB dhe versionin e SBAT, kur në GRUB u gjetën dobësi.
Më poshtë është përkthimi i shënimit të Garrett:
Kur po zhvillohej specifikimi i UEFI Secure Boot, të gjithë pjesëmarrësit ishin, le të themi, pak naivë. Modeli kryesor i sigurisë së Secure Boot është se të gjithë kodet që ekzekutohen në një mjedis të privilegjuar në nivelin e bërthamës duhet të verifikohen para se të ekzekutohen — firmware-i verifikon bootloader-in, bootloader-i verifikon bërthamën, bërthama verifikon çdo kod shtesë të ngarkuar gjatë ekzekutimit, dhe tani kemi një mjedis të besueshëm për të imponuar çdo politikë tjetër sigurie që duam. Është e qartë se njerëzit mund të gabojnë, por specifikimi kishte parashikuar një mënyrë për të anuluar komponentët e nënshkruar që ishin bërë të pasigurt: thjesht shtoni hash-in e kodit të dyshimtë në një variabël dhe pastaj refuzoni të ngarkoni ndonjë gjë me atë hash, edhe nëse është nënshkruar nga një çelës i besueshëm.
Fatkeqësisht, siç doli, problemi është në shkallë. Çdo shpërndarje Linux që operon në ekosistemin e Secure Boot gjeneron skedarë binary të ngarkuesit të vet, dhe çdo një prej tyre ka hash-in e tij. Nëse zbulohet një cenueshmëri në kodin burimor të një ngarkuesi të tillë, duhet të tërhiqen një numër i madh skedarësh binary të ndryshëm. Dhe hapësira për të ruajtur ndryshoren që përmban të gjithë këto hash-e është e kufizuar. Thjesht nuk do të mjaftojë vend për të shtuar një grup të ri hash-esh çdo herë që zbulohet se GRUB (ngarkuesi, i shkruar fillimisht në një kohë kur mbrojtja e ngarkesës nuk ishte praktikuar, dhe që ka disa parserë të veçantë për imazhet img, si dhe një parser për fonte) ka një tjetër mekanizëm për një sulmues për ta bërë ta ekzekutojë kodin e tij të mirëfilltë, dhe prandaj ishte e nevojshme një zgjidhje tjetër.
Kjo zgjidhje ishte SBAT. Koncepti i përgjithshëm i SBAT është mjaft i thjeshtë. Çdo komponent i rëndësishëm në zinxhirin e ngarkesës shpall një brez sigurie, i cili përfshihet në skedarin binary të nënshkruar. Kur zbulohet një cenueshmëri dhe zgjidhet, ky brez rritet. Pastaj mund të lëshohet një përditësim që përcakton brezin minimal — komponentët e ngarkesës do të shikojnë elementin pasardhës në zinxhir, do të krahasojnë emrin e tij dhe numrin e brezit me ato që ruhen në ndryshoren e BIOS-it dhe do të vendosin nëse ta ekzekutojnë apo jo, duke u bazuar në këto informacione. Në vend që të tërhiqen një numër i madh hash-esh të veçantë, mund të lëshohet një përditësim i vetëm që thotë: “Çdo version i GRUB me brez sigurie nën këtë numër konsiderohet i paqartë”.
Pse u bë kjo papritur e rëndësishme? SBAT u zhvillua nga bashkësia Linux dhe Microsoft, dhe Microsoft vendosi të lëshojë një përditësim për Windows që u thoshte sistemeve të mos i besojnë versionet e GRUB me brez sigurie nën një nivel të caktuar. Kjo u bë sepse këto versione të GRUB kishin reale cenueshmëri në siguri që lejonin sulmuesit të thyjnë zinxhirin e ngarkesës së sigurt të Windows, dhe kemi parë shembuj të vërtetë të malware që donte ta bënte këtë (Black Lotus përdori një cenueshmëri në ngarkuesin e Windows, por cenueshmëria në GRUB ishte po aq efektive). Nëse e shohim këtë thjesht nga pikëpamja e sigurisë, kjo është një dëshirë plotësisht legjitime.
Tani lidhur me mesazhin "Diçka nuk shkoi ashtu siç duhet" dhe pamundësinë e shkarkimit si rezultat i këtij përditësimi. Ky mesazh i jep shim, dhe jo ndonjë kodi nga Microsoft. Shim merr parasysh përditësimet SBAT, dhe, për të mos shkelur parimet e sigurisë të pranuara nga bootloaderat e tjerë në sistem, edhe pse Microsoft lëshoi një përditësim SBAT, bootloaderi Linux refuzon të ngarkojë versionet e vjetra të GRUB. Gjithçka funksionon siç duhet.
Problemi me të cilin përballen njerëzit është se disa distribucione Linux nuk kanë lëshuar versione GRUB me një brez më të ri të sigurisë, dhe prandaj këto versione GRUB konsiderohen të pasigurta (duhet theksuar se GRUB nënshkruhet nga vetë distribucionet dhe jo nga Microsoft, kështu që nuk ka ndonjë vonesë të sjellë nga jashtë). Nga ana e Microsoft, përditësimi i Windows Update duhej të aplikonte përditësimin SBAT vetëm për sistemet që punojnë vetëm me Windows, ndërsa çdo instalim me dy ngarkesa do të mbetej i pambrojtur nga sulmet derisa distribucioni i instaluar të përditësonte GRUB dhe të rifreskonte brez të SBAT. Fatkeqësisht, siç është e dukshme tani, kjo nuk ka funksionuar ashtu siç ishte menduar, dhe së paku disa sisteme me dy ngarkesa zbatuan përditësimin, por Shim i këtij distribucioni refuzoi të ngarkonte GRUB e këtij distribucioni.
Çfarë është përmbledhja? Microsoft (për arsye të njohura) nuk donte që Windows të sulmohej me një version të dobët të GRUB-it, që mund të manipuloheshin për të ekzekutuar kod të rastësishëm dhe më pas të futnin një bootkit në kernelin e Windows gjatë ngarkimit. Microsoft e arriti këtë duke lëshuar një përditësim Windows që përditësoi variablën SBAT, duke treguar që versionet e dobëta të GRUB-it nuk duhet të ngarkohen në këto sisteme. Bootloaderi i fazës fillestare i ofruar nga distribucioni lexonte këtë variablë, lexonte seksionin SBAT nga kopja e instaluar të GRUB dhe kuptoi që ato ishin në konflikt dhe refuzoi të ngarkonte grub me mesazhin "Diçka nuk shkoi ashtu siç duhet". Ky përditësim nuk duhej të aplikohesh në sistemet me dy ngarkesa, por ende u aplikua.
Në përgjithësi:
1) Microsoft e aplikoi përditësimin në sistemet ku nuk duhej të aplikohej
2) Disa distribucione Linux nuk e përditësuan bootloaderin GRUB dhe brezine sigurisë SBAT, kur u zbuluan dobësi në GRUB.
Si përfundim, disa njerëz nuk mund të ngarkojnë sistemet e tyre. Mendoj se ka shumë fajtorë këtu. Microsoft duhej të kishte bërë më shumë teste për t'u siguruar se instalimet me dy ngarkesa mund të identifikohen saktë. Por edhe distribucionet që ofrojnë bootloader të nënshkruar duhet të sigurohen që t'i përditësojnë ato dhe të përmirësojnë gjeneratën e sigurisë për t'iu përshtatur, sepse ndryshe ata ofrojnë një vektor sulmi që mund të përdoret për të hakuar sisteme të tjera operative, dhe kjo është një lloj shkeljeje e kontratës publike rreth të gjithë kësaj.
Fatkeqësisht, viktimat këtu janë kryesisht përdoruesit përfundimtarë, të cilët përballen me faktin se sistemi papritur refuzon të ngarkojë atë OS që ata duan të ngarkojnë. Kjo kurrë nuk duhet të ndodhë. Nuk mendoj se një anketë për përdoruesit përfundimtarë nëse ata duan përditësime të sigurisë së ngarkesës do të japë një rezultat të mirë, dhe ndonëse pak e pranoj që ngarkesa e sigurt UEFI nuk është diçka që i sjell dobi shumicës së përdoruesve përfundimtarë, gjithashtu është diçka që nuk dëshiron ta zbulojnë pas incidenteve të tilla, prandaj simpatizoj me faktin që është e aktivizuar përparësisht, prandaj mbështes aktivizimin e saj përparësisht dhe ndaj zgjedhjen e Microsoft, përveç përpjekjes dështake për të shmangur përditësimin në sistemet me dy ngarkesa.
Në çdo rast, kam qenë shumë i angazhuar në implementimin e këtij mekanizmi për Linux në vitin 2012 dhe kam shkruar prototipin e parë Shim (i cili tani është një ngarkues shumë më i mirë, i mbështetur nga një grup më të gjerë njerëzish, dhe të cilin nuk e kam prekur për disa vjet), prandaj nëse dëshironi të akuzoni dikë, ju lutem mos hezitoni të më akuzoni mua. Kjo është diçka që nuk duhej të kishte ndodhur, dhe nëse nuk jeni Microsoft ose distribucion Linux, atëherë nuk është faji juaj. Më vjen keq.
Burimi: opennet.ru
