Matthew Garrett, një zhvillues i njohur i kernel-it Linux, i cili ka marrë çmimin nga Fondi i Softuerit të Hapur 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 vulnerabilitetet në bootloader pa anulluar nënshkrimin digjital, si dhe rolin e tij në incidentin e fundit me një përditësim për Windows, i cili çoi në ndërprerjen e ngarkimit të disa distribuconve Linux të instaluara paralelisht me Windows në sisteme që kishin aktivizuar UEFI Secure Boot. Nëse flasim shkurt, fajtorët janë si kompania Microsoft, e cila nuk e testoi plotësisht përditësimin dhe e aplikoi atë në sisteme të cilave nuk duhej t'i aplikohej, ashtu edhe zhvilluesit e disa distribuconve Linux, të cilët nuk e përditësuan bootloader-in GRUB dhe numrin e gjeneratës SBAT, kur në GRUB u zbuluan vulnerabilitete.
Më poshtë është përkthimi i shënimit të Garrett:
Kur u zhvillua 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 çdo kod që ekzekutohet në një ambient të privilegjuar në nivelin e kernel-it duhet të kontrollohet përpara se të ekzekutohet — firmuara kontrollon bootloader-in, bootloader-i kontrollon kernel-in, dhe kernel-i kontrollon çdo kod të mëtejshëm të ngarkuar gjatë ekzekutimit, dhe tani kemi një ambient 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 parashikoi një mënyrë për të anulluar komponentët e nënshkruar që ishin të pasigurt: thjesht shtoni një hash të kodit të pasigurt në një variabël dhe pastaj refuzoni të ngarkoni ndonjë gjë me këtë hash, edhe nëse është nënshkruar me një çelës të besueshëm.
Fatkeqësisht, siç u zbulua, problemi është në përmasa. Çdo distribucion Linux që funksionon në ekosistemin e Secure Boot gjeneron skedarë binarë bootloader-i të vetin, dhe secili prej tyre ka hash-in e vet. Nëse në kodin burimor të atij bootloader-i zbulohet një vulnerabilitet, duhet të anullohen një numër i madh i skedarëve binarë të ndryshëm. Dhe hapsira për të ruajtur variablen që përmban të gjithë këto hash-e është e kufizuar. Thjesht nuk ka hapësirë për të shtuar një grup të ri hash-esh çdo herë që zbulohet se GRUB (bootloader-i, i shkruar fillimisht në një kohë kur mbrojtja nga ngarkimi nuk praktikoheshte, dhe me disa parser të veçantë img-file, si dhe parser fontesh) ka një mekanizëm tjetër për një sulmues për ta detyruar atë të ekzekutojë kod të rastësishëm, prandaj ishte e nevojshme një zgjidhje tjetër.
Kjo zgjidhje ishte SBAT. Koncepti i përgjithshëm i SBAT-it është mjaft i thjeshtë. Çdo komponent i rëndësishëm në zinxhirin e ngarkimit shpall një gjeneratë sigurie, e cila përfshihet në skedarin binar të nënshkruar. Kur zbulohet dhe adresohet një vulnerabilitet, kjo gjeneratë rritet. Pastaj mund të lëshohet një përditësim që përcakton gjeneratën minimale — komponentët e ngarkimit do të shikojnë në elementin e ardhshëm në zinxhir, do të krahasonin emrin dhe numrin e gjeneratës me ato që ruhen në variablin e firmware-it dhe do të vendosnin nëse do ta ekzekutojnë apo jo, bazuar në këtë. Në vend të anulimit të një numri të madh hash-esh të veçanta, mund të lëshohet një përditësim i vetëm, i cili thotë: "Çdo version i GRUB me gjeneratë sigurie më të ulët se ky numër konsiderohet i pamundur."
Por pse kjo u bë e rëndësishme papritur? SBAT u zhvillua në bashkëpunim me komunitetin Linux dhe Microsoft, dhe Microsoft vendosi të lëshojë një përditësim për Windows, i cili u thoshte sistemeve të mos besonin versionet e GRUB me gjeneratë sigurie më të ulët se një nivel të caktuar. Kjo u bë sepse këto versione të GRUB kishin vulnerabilitete reale në siguri që lejonin kriminelët të thyhen zinxhirin e ngarkimit të sigurt të Windows, dhe ne kemi parë shembuj realë të malware që donte të bënte këtë (Black Lotus shfrytëzoi një vulnerabilitet në bootloader-in e Windows, por vulnerabiliteti në GRUB ishte po aq efektiv). Nëse e shikoni këtë vetëm nga këndvështrimi i sigurisë, kjo është një dëshirë plotësisht të arsyeshme.
Tani për sa i përket mesazhit "Dicka nuk shkoi mirë" dhe paaftësisë për të ngarkuar si rezultat i këtij përditësimi. Kjo jepet nga shim, jo nga ndonjë kod nga Microsoft. Shim merr parasysh përditësimet SBAT, dhe, për të mos shkelur parimet e sigurisë që janë pranuar nga bootloader-at e tjerë në sistem, dhe megjithëse Microsoft lëshoi një përditësim SBAT, pikërisht bootloader-i Linux në rezultat refuzon të ngarkojë versionet e vjetra të GRUB. Gjithçka funksionon siç duhet.
Problemi me të cilin njerëzit u përballën është se disa shpërndarje të Linux-it nuk lëshuan versione të GRUB me një brez më të ri të sigurisë, dhe prandaj këto versione GRUB konsiderohen të pasigurta (duhet të theksohet se GRUB nënshkruhet nga vetë shpërndarjet, dhe jo nga Microsoft, kështu që nuk ka ndonjë vonesë të sjellë nga jashtë). Qëllimi i Microsoft-it ishte që përditësimi i Windows Update 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 ndjeshëm ndaj sulmeve derisa shpërndarja e instaluar të azhurnonte GRUB dhe të përditësonte brezin SBAT. Fatkeqësisht, siç është bërë e qartë tani, kjo nuk funksionoi siç ishte parashikuar, dhe, të paktën, disa sisteme me dy ngarkesa aplikuan përditësimin, ndërsa Shim i kësaj shpërndarjeje refuzoi të ngarkonte GRUB të kësaj shpërndarjeje.
Cili është përfundimi? Microsoft (për arsye të kuptueshme) nuk donte që Windows-i të ishte i ndjeshëm ndaj një versioni të pasigurt GRUB, i cili mund të përballej për të ekzekutuar kod të rastësishëm dhe më pas të futte një bootkit në bërthamat e Windows gjatë ngarkimit. Microsoft e arriti këtë duke lëshuar një përditësim të Windows-it që azhurnoi variablën SBAT, duke treguar se versionet e pasigurta të GRUB nuk duhet të ngarkoheshin në këto sisteme. Bootloader-i i parë i ofruar nga shpërndarja lexonte këtë variabël, lexonte seksionin SBAT nga kopja e instaluar të GRUB, kuptonte se ato konfliktuan, dhe refuzonte të ngarkonte grub me mesazhin “Dikush ka shkuar keq”. Ky përditësim nuk duhej të aplikohej në sistemet me dy ngarkesa, por megjithatë u aplikua.
Në përgjithësi:
1) Microsoft aplikoi përditësimin në sistemet ku nuk duhej të aplikonte
2) Disa shpërndarje të Linux-it nuk e azhurnuan bootloader-in GRUB dhe brezin e sigurisë SBAT kur u zbuluan ndjeshmëri në GRUB.
Si rezultat, disa njerëz nuk mund të ngarkojnë sistemet e tyre. Mendoj se ka shumë fajtorë në këtë rast. Microsoft do të duhej të bënte më shumë teste për të siguruar që instalimet me dy ngarkesa mund të identifikoheshin saktësisht. Por gjithashtu shpërndarjet që ofrojnë bootloaders të nënshkruar duhet të sigurojnë që t'i azhurnojnë ato dhe të përditësojnë brezin e sigurisë për t'u përputhur, sepse ndryshe ato ofrojnë një vektor sulmi që mund të përdoret për të hakuar sisteme të tjera operative, dhe kjo është një lloj shkeljeje e marrëveshjes së përgjithshme për rreth një gjëje të tillë.
Fatkeqësisht, viktimat këtu janë kryesisht përdoruesit finalë që janë përballur me faktin se sistemi refuzon papritur të ngarkojë sistemin operativ që ata duan të ngarkojnë. Kjo nuk duhet të ndodhte kurrë. Nuk mendoj se një anketë e përdoruesve finalë nëse ata duan përditësime të sigurisë në ngarkim do të ketë një rezultat të mirë, dhe ndonëse unë si duket jem pak i prirur në mendimin se ngarkimi i sigurt UEFI nuk është diçka që sjell përfitim për shumicën e përdoruesve, është gjithashtu një gjë që nuk dëshiron ta zbulosh pas incidenteve të tilla, prandaj ndjej se është e mirë që ai është aktivizuar ndryshe, kështu që përkrah vendimin e Microsoft-it, përveç një përpjekjeje të dështuar për të shmangur përditësimin në sistemet me dy ngarkesa.
Në çdo rast, unë kam qenë shumë i përfshirë në zbatimin e këtij mekanizmi për Linux në vitin 2012 dhe kam shkruar prototipin e parë Shim (i cili tani është një bootloader shumë më i mirë, mbështetur nga një gamë më e gjerë njerëzish, dhe nuk e kam prekur për disa vjet), kështu që nëse dëshiron të akuzosh dikë, mos hezito të më akuzosh mua. Kjo është diçka që nuk duhej të ndodhte, dhe nëse nuk je Microsoft ose një shpërndarje Linux, atëherë nuk është faji yt. Më fal.
Burimi: opennet.ru
