Framework a livrat aproximativ 200.000 de calculatoare Linux cu componente UEFI semnate care conțineau o comandă periculoasă, oferind astfel o cale de ocolire a protecției Secure Boot. Firma de securitate firmware Eclypsium a descoperit problema, care implică o comandă numită mm, destinată diagnosticelor low-level, dar capabilă să modifica memoria și să compromită verificarea semnăturilor la încărcarea modulelor UEFI.
Comenzile mm permit citire și scriere directă în memorie, utilă pentru depanarea la nivel de firmware, însă această capacitate prezintă și un risc semnificativ. Pe sistemele Framework, mm poate suprascrie pointerul de securitate gSecurity2 cu valoarea NULL sau îl poate redirecționa către o funcție care returnează constant succes fără nicio verificare. În practică, asta face posibil ca orice modul, semnat sau nesemnat, să fie acceptat ulterior, permițând unui atacator să încarce bootkit-uri precum BlackLotus, HybridPetya sau Bootkitty. Aceste bootkit-uri ocolesc controalele sistemului de operare și pot persista chiar după reinstalarea OS-ului.
Cercetătorii au demonstrat că atacul poate fi automatizat prin scripturi care rulează la inițializare, astfel încât supraviețuiește repornirilor. Eclypsium precizează că nu este vorba despre o compromitere a lanțului de semnare în sine, ci despre includerea accidentală a comenzii mm în UEFI shell-urile semnate pe care Framework le-a livrat clienților. După semnalarea problemei, Framework a început lucrul la remedieri.
Estimările pun impactul la aproximativ 200.000 de unități Framework; modelele și versiunile de firmware afectate și planificate pentru remediere includ Framework 13 pe mai multe generații de procesoare Intel și AMD, Framework 16 (AMD Ryzen 7040) și Framework Desktop (AMD Ryzen AI 300 MAX). Pentru unele modele, corecțiile sunt deja furnizate în anumite versiuni de firmware, iar pentru altele sunt planificate actualizări DBX care vor bloca componentele problematice la nivelul bazei de date a semnăturilor. Raportul menționează versiuni de firmware precum 3.24, 3.18, 3.08, 3.06, 3.16, 3.04, 3.01 și altele, în funcție de model și generație.
Utilizatorilor afectați li se recomandă să instaleze imediat actualizările de securitate disponibile. Pentru modelele care încă nu au patch, sunt esențiale măsurile secundare: limitarea accesului fizic la dispozitiv rămâne o apărare importantă; o soluție temporară sugerată este ștergerea cheii DB a Framework din BIOS, ceea ce împiedică utilizarea shell-ului semnat problematic. Aceste măsuri rămân valabile până la lansarea update-urilor de firmware și a actualizărilor DBX de către producător.
Cazul ridică aspecte mai largi de securitate: instrumentele de diagnosticare, concepute pentru a ajuta, pot introduce riscuri dacă ajung în producție; verificarea riguroasă a componentelor semnate înainte de livrare e esențială; iar amenințările la nivel de boot sunt mai greu de eliminat decât un software obișnuit. Exemplul Framework subliniază necesitatea unei atenții sporite în procesele de semnare și distribuire a firmware-ului, precum și importanța actualizărilor DBX pentru blocarea componentelor periculoase. Când un producător precum Framework, recunoscut pentru laptopuri modulare și ușor reparabile, se confruntă cu astfel de probleme, devine clar că transparența și reacția rapidă sunt cruciale pentru menținerea încrederii utilizatorilor.
Framework 13 (mai multe versiuni de firmware, ex. 3.08, 3.18, 3.24) și Framework 16 sunt menționate explicit în remediile anunțate. Aplicați actualizările când devin disponibile și limitați accesul fizic la echipament până atunci. Credeți că producătorii ar trebui să elimine complet instrumentele de diagnostic din build-urile finale sau să le semneze diferit pentru a evita astfel de situații?
Fii primul care comentează