Matthew Garrett, cunoscut dezvoltator al nucleului Linux, care a primit în trecut un premiu de la Fondul de Software Liber pentru contribuțiile sale la dezvoltarea software-ului liber, a vorbit despre esența mecanismului SBAT (Secure Boot Advanced Targeting), creat pentru a bloca vulnerabilitățile în bootloader fără a retracta semnătura digitală, precum și despre rolul său în incidentul recent legat de actualizarea pentru Windows, care a dus la oprirea încărcării unor distribuții Linux instalate paralel cu Windows pe sisteme cu UEFI Secure Boot activat. Pe scurt, responsabili sunt atât compania Microsoft, care nu a testat complet actualizarea și a aplicat-o pe sisteme pentru care nu era destinată, cât și dezvoltatorii unor distribuții Linux, care nu au actualizat bootloader-ul GRUB și versiunea SBAT, atunci când au fost descoperite vulnerabilități în GRUB.
Iată traducerea notiței lui Garrett:
Când s-a desfășurat dezvoltarea specificației UEFI Secure Boot, toți participanții au fost, să spunem, puțin naivi. Modelul principal de securitate al Secure Boot constă în faptul că tot codul care rulează într-un mediu privilegiat la nivel de nucleu trebuie să fie verificat înainte de executare — firmware-ul verifică bootloader-ul, bootloader-ul verifică nucleul, nucleul verifică orice cod suplimentar încărcat în timpul execuției, iar acum avem un mediu de încredere pentru impunerea oricărei alte politici de securitate pe care o dorim. Este evident că oamenii pot greși, dar specificația prevăzuse un mod de a revoca componentele semnate care s-au dovedit a fi nesigure: pur și simplu adăugați hash-ul codului nesigur într-o variabilă și apoi refuzați să încărcați orice cu acel hash, chiar dacă este semnat cu o cheie de încredere.
Din păcate, s-a dovedit că problema este la scară. Fiecare distribuție Linux care funcționează în ecosistemul Secure Boot generează propriile fișiere binare pentru bootloader, fiecare având propriul său hash. Dacă o vulnerabilitate este descoperită în codul sursă al acestui bootloader, este necesar să se revoce un număr mare de fișiere binare diferite. Iar memoria pentru stocarea variabilei care conține toate aceste hash-uri este limitată. Pur și simplu nu va fi suficient spațiu pentru a adăuga un nou set de hash-uri de fiecare dată când se constată că GRUB (bootloader-ul, scris inițial în vremuri când protecția bootării nu era practicată și având mai mulți parseri pentru imagini img, precum și parseri de fonturi) are încă un mecanism pentru un atacator să-l convingă să execute cod arbitrar, așadar s-a impus o altă soluție.
Soluția a fost SBAT. Conceptul general al SBAT este destul de simplu. Fiecare componentă importantă din lanțul de boot declară o generație de securitate, care este inclusă în fișierul binar semnat. Atunci când o vulnerabilitate este descoperită și soluționată, această generație este incrementată. Apoi se poate lansa o actualizare care definește generația minimă - componentele de boot se vor uita la următorul element din lanț, comparându-i numele și numărul generației cu cele stocate în variabila firmware-ului, și vor decide dacă să-l execute sau nu pe baza acestei informații. În loc să se revoce un număr mare de hash-uri individuale, se poate lansa o actualizare care pur și simplu spune: „Orice versiune GRUB cu generația de securitate mai mică decât acest număr este considerată nesigură.”
De ce a devenit această problemă atât de relevantă? SBAT a fost dezvoltat în colaborare între comunitatea Linux și Microsoft, iar Microsoft a decis să lanseze o actualizare pentru Windows care să spună sistemelor să nu aibă încredere în versiunile GRUB cu generația de securitate mai mică decât un anumit nivel. Aceasta s-a făcut deoarece aceste versiuni GRUB aveau vulnerabilități reale de securitate care permiteau atacatorilor să compromită lanțul de boot sigur al Windows, și am văzut exemple reale de malware care dorea să facă acest lucru (Black Lotus a folosit o vulnerabilitate în bootloader-ul Windows, dar vulnerabilitatea din GRUB a fost la fel de eficientă). Privind la acest lucru pur din perspectiva securității, este o dorință complet legitimă.
În ceea ce privește mesajul „Ceva nu a mers deloc bine” și imposibilitatea de a încărca din cauza acestei actualizări. Acesta este generat de shim, nu de vreun cod de la Microsoft. Shim-ul ține cont de actualizările SBAT și, pentru a nu încălca principiile de securitate adoptate de alte bootloadere din sistem, și, deși Microsoft a lansat o actualizare SBAT, bootloaderul Linux refuză să încarce vechile versiuni GRUB. Totul funcționează așa cum ar trebui.
Problema cu care s-au confruntat oamenii este că mai multe distribuții Linux nu au lansat versiuni GRUB cu o nouă generație de securitate, iar aceste versiuni GRUB sunt considerate nesigure (este de menționat că GRUB este semnat de distribuții însele, nu de Microsoft, așa că nu există o întârziere impusă din exterior). Conform intenției Microsoft, actualizarea Windows Update ar fi trebuit să aplice actualizarea SBAT doar sistemelor care rulează exclusiv Windows, iar orice instalări cu dublă încărcare ar fi rămas vulnerabile la atacuri până când distribuția instalată nu actualizează GRUB și nu îmbunătățește generația SBAT. Din păcate, așa cum este evident acum, acest lucru nu a funcționat așa cum era planificat, iar cel puțin câteva sisteme cu dublă încărcare au aplicat actualizarea, iar Shim-ul acestei distribuții a refuzat să încarce GRUB-ul acestei distribuții.
Care este concluzia? Microsoft (din motive evidente) nu a dorit ca Windows să poată fi atacat printr-o versiune vulnerabilă de GRUB, care ar putea fi păcălită să execute cod arbitrar și apoi să implanteze un bootkit în nucleul Windows în timpul încărcării. Microsoft a realizat acest lucru prin lansarea unei actualizări Windows, care a actualizat variabila SBAT, indicând că versiunile vulnerabile de GRUB nu trebuiau încărcate pe aceste sisteme. Bootloaderul de primă etapă furnizat de distribuție a citit această variabilă, a citit secțiunea SBAT din copia GRUB instalată, a înțeles că există un conflict și a refuzat să încarce grub cu mesajul „Ceva nu a mers deloc bine”. Această actualizare nu ar fi trebuit aplicată sistemelor cu dublă încărcare, dar totuși a fost aplicată.
În general:
1) Microsoft a aplicat actualizarea sistemelor la care nu ar fi trebuit aplicată
2) Unele distribuții Linux nu au actualizat bootloader-ul GRUB și generația de securitate SBAT atunci când în GRUB au fost descoperite vulnerabilități.
Din păcate, unii oameni nu pot să își încarce sistemele. Cred că aici sunt mulți vinovați. Microsoft ar fi trebuit să facă mai multe teste pentru a se asigura că instalările cu dublu boot pot fi identificate corect. Dar și distribuțiile care oferă bootloadere semnate ar trebui să se asigure că le actualizează și că îmbunătățesc generația de securitate pentru a se conforma, deoarece în caz contrar oferă un vector de atac care poate fi folosit pentru a compromite alte sisteme de operare, iar acesta este un fel de încălcare a contractului social în jurul întregului acestuia.
Din păcate, victimele aici sunt în principal utilizatorii finali, care se confruntă cu faptul că sistemul refuză brusc să încarce acel OS pe care doresc să-l ruleze. Acest lucru nu ar trebui să se întâmple niciodată. Nu cred că un sondaj printre utilizatorii finali cu privire la dorința de a avea actualizări pentru sistemul de bootare sigur va duce la un rezultat bun, și deși mă inclin vag să cred că bootarea sigură UEFI nu este ceva ce aduce beneficii majorității utilizatorilor finali, este de asemenea ceva ce nu vrei să descoperi după astfel de incidente, așa că simpatizez cu faptul că este activată implicit, de aceea susțin activarea ei implicit și împărtășesc alegerea Microsoft, cu excepția încercării nereușite de a evita actualizarea pe sistemele cu dublu boot.
Oricum, am fost foarte implicat în implementarea acestui mecanism pentru Linux în 2012 și am scris primul prototip Shim (care acum este un bootloader semnificativ mai bun, suportat de un cerc mai larg de oameni, și la care nu m-am atins de câțiva ani), așa că dacă doriți să acuzați pe cineva anume, vă rog să nu ezitați să mă acuzați pe mine. Acesta este un lucru care nu ar fi trebuit să se întâmple, iar dacă nu ești Microsoft sau un distribuitor Linux, atunci nu este vina ta. Îmi pare rău.
Sursa: opennet.ro
