Nimic ciudat, zero drame ... Dar a fost descoperită alta vulnerabilitate, CVE-2020-10713, care afectează încărcătorul de încărcare GRUB2 și Secure Boot. O publicație a echipei de cercetare Eclypsium este cea care a stat în spatele acestei descoperiri și pe care au numit-o BootHole. Chiar și Microsoft a publicat o intrare pe portalul său de securitate care avertizează despre aceasta și susține că există o soluție complicată în acest moment.
BootHole Este o vulnerabilitate de depășire a bufferului care afectează miliarde de dispozitive cu GRUB2 și chiar și altele fără GRUB2 care utilizează Secure Boot, cum ar fi Windows. În clasificarea CVSS a fost notat ca 8.2 din 10, ceea ce înseamnă că este un risc ridicat. Și este că un atacator ar putea profita de acest lucru pentru a putea executa cod arbitrar (inclusiv malware) introdus în timpul procesului de boot, chiar și cu Secure Boot activat.
Atât de mult Dispozitive rețea, servere, stații de lucru, desktopuri și laptopuri, precum și alte dispozitive precum SBC-uri, anumite dispozitive mobile, dispozitive IoT etc., ar fi afectate.
Mai mult, conform Eclypsium, va fi complicat de atenuat și va fi nevoie de timp pentru a găsi o soluție. Va necesita o revizuire profundă a încărcătorilor de încărcare, iar furnizorii ar trebui să lanseze noi versiuni de încărcătoare de încărcare semnate de UEFI CA. Va fi nevoie de eforturi coordonate între dezvoltatorii din sursa deschisă Microsoft și comunitatea de colaborare și alți proprietari de sistem afectați pentru a elimina BootHole.
De fapt, au făcut un pentru a face lista pentru a putea repara BootHole în GRUB2 și aveți nevoie de:
- Patch pentru actualizarea GRUB2 și eliminarea vulnerabilității.
- Că dezvoltatorii de distribuții Linux și alți furnizori lansează actualizările pentru utilizatorii lor. Atât la nivel de GRUB2, instalatori, cât și de schimbători.
- Noile piese trebuie să fie semnate de Microsoft UEFI CA pentru terți.
- Administratorii sistemelor de operare vor trebui, evident, să se actualizeze. Dar trebuie să includă atât sistemul instalat, cât și imaginile din programul de instalare și, de asemenea, mediile de recuperare sau de pornire pe care le-au creat.
- Lista de revocare UEFI (dbx) va trebui, de asemenea, să fie actualizată în firmware-ul fiecărui sistem afectat pentru a preveni executarea codului în timpul bootării.
Cel mai rău lucru este că, atunci când vine vorba de firmware, trebuie să fii atent și să fii atent să nu ajungi la probleme și să rămână computerele în modul cărămidă.
În acest moment, companii precum Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team și OEM-uri, precum și furnizori de software, deja lucrează pentru a remedia problema. Cu toate acestea, va trebui să așteptăm pentru a vedea primele patch-uri.
UPDATE
Dar subestimarea eficienței dezvoltatorilor și a comunității ar fi o prostie. Deja există mai mulți candidați la patch pentru a-l atenua care vin de la companii precum Red Hat, Canonical etc. Aceștia au semnalat această problemă ca fiind o prioritate absolută și aceasta dă roade.
Problema? Problema este că aceste patch-uri provoacă probleme suplimentare. Îmi amintește de ceea ce s-a întâmplat cu patch-urile Metldown și Spectre, că uneori remediul este mai rău decât boala ...