O vulnerabilitate nepatch-uită din EDK II expune serverele care pornesc din rețea înainte de Secure Boot

Un buffer overflow care a stat aproape șaisprezece ani în codul de referință open-source pentru UEFI poate bloca un server în timp ce pornește din rețea și, în cel mai rău caz, poate rula cod controlat de atacator înainte ca Secure Boot să se fi inițializat. Vulnerabilitatea are identificatorul CVE-2026-97631 și un scor CVSS de 9,5. Se află în EDK II, baza de cod TianoCore pe care o folosesc aproape toți producătorii de firmware. Există o corecție în ramura principală de dezvoltare a proiectului, dar la 28 octombrie 2026 nicio versiune stabilă EDK II nu o include, iar majoritatea administratorilor de servere nu au încă nimic de instalat.

Ce s-a întâmplat

EDK II include stiva de pornire din rețea PXE, care permite unei mașini să-și descarce imaginea de boot din rețea în loc de pe un disc local. În timpul unui boot PXE, driverul acceptă mesaje de eroare ICMP și răspunsuri scurte de stare din rețea și le copiază într-un buffer fix de 504 octeți. Verificările de lungime din jurul acestei copieri sunt greșite atât în codul IPv4, cât și în cel IPv6, așa că un singur mesaj special construit, mai lung de 504 octeți, depășește bufferul și suprascrie memoria adiacentă cu date alese de atacator.

Bucla de copiere defectă provine dintr-un commit din noiembrie 2010. Toate versiunile EDK II până la edk2-stable202608 inclusiv, eticheta stabilă curentă din august 2026, o conțin. Pornirea PXE este activată implicit în build-ul standard EDK II, motiv pentru care atât de multe produse derivate sunt afectate: producătorii independenți de BIOS AMI, Insyde și Phoenix, fork-ul întărit Project Mu al Microsoft și pachetele edk2 livrate de Red Hat Enterprise Linux 8, 9 și 10, SUSE și Debian, folosite în principal ca firmware UEFI pentru mașini virtuale.

Dezvăluirea nu a decurs conform planului. O publicare coordonată era programată pentru ianuarie 2027, însă un pull request deschis pe 28 septembrie 2026 a menționat public CVE-ul și a inclus patch-ul. TianoCore și-a publicat apoi advisory-ul pe 22 octombrie, corecția fiind deja integrată în ramura principală din 15 octombrie. Microsoft a reacționat rapid și a lansat build-uri Project Mu cu corecția pe 26 octombrie. Pe partea de hardware, Intel afirmă că niciunul dintre produsele sale comerciale aflate sub suport de securitate nu este cunoscut ca afectat și că propriul cod de referință nu include funcționalitatea vulnerabilă, deși un producător de plăci ar putea-o adăuga. Arm spune că vulnerabilitatea nu se aplică direct portofoliului său. AMD, AMI, Phoenix, Insyde, Microsoft și marii furnizori de cloud nu au confirmat public starea firmware-ului lor, așa că pentru multe parcuri de servere răspunsul onest de astăzi este „necunoscut”.

De ce contează

Pericolul stă în momentul execuției. Codul injectat prin această vulnerabilitate rulează în interiorul firmware-ului, înainte ca Secure Boot, measured boot și orice control de la nivelul sistemului de operare să fi verificat ceva. Atacatorul nu are nevoie de parole și nici de acces prealabil la mașină, ci doar de posibilitatea de a o atinge în rețea în fereastra scurtă în care pornește prin PXE.

Consecințele se împart în două niveluri. Cel simplu este refuzul serviciului: boot-ul se blochează și mașina nu mai pornește. Un parc de servere care depinde de PXE pentru provizionare sau pentru noduri fără disc poate fi scos din funcțiune pachet cu pachet. Execuția de cod este considerabil mai grea și mult mai puțin fiabilă, pentru că payload-ul trebuie adaptat la build-ul exact de firmware. Codul plantat astfel rulează o singură dată și nu persistă de la sine, dar o singură execuție atât de devreme în lanțul de boot este suficientă pentru a instala ceva care persistă sau pentru a ajunge la secrete pe care procesul de boot încă le deține, cum ar fi cheile de criptare a discului eliberate de TPM. Într-un scenariu de furt sau de acces de scurtă durată la rețea, aceasta este o cale de a sparge criptarea completă a discului pe un server sau pe un endpoint.

Două nuanțe sunt importante. În primul rând, nu există dovezi de exploatare în lumea reală: CVE-ul nu figura în catalogul Known Exploited Vulnerabilities al CISA la actualizarea din 27 octombrie și nimeni nu a raportat că l-ar fi văzut folosit. În al doilea rând, nu este o poartă de intrare din internet. Red Hat și SUSE evaluează vectorul de atac ca fiind de rețea adiacentă, iar atacatorul realist este un insider sau cineva care are deja un punct de sprijin într-un segment local și vrea să meargă mai departe. Totuși, patch-ul este acum public, iar oricine poate citi un diff își poate da seama exact cum se declanșează overflow-ul.

Nu este nici prima dată când stiva PXE lasă EDK II descoperit. Setul de nouă vulnerabilități PixieFail, dezvăluit în ianuarie 2024, a lovit aceeași componentă, iar campaniile de fuzzing care au urmat nu au prins-o pe aceasta.

Ce e de făcut

Inventariați ce pornește din rețea. Hosturile de provizionare bare-metal, nodurile de calcul fără disc, clienții thin și mașinile virtuale care rulează firmware bazat pe EDK II intră toate în această categorie. Dacă nu le puteți enumera, nu le puteți proteja.
Dezactivați PXE acolo unde nu este necesar. Este activat implicit în majoritatea build-urilor. Oprirea pornirii din rețea în meniul de firmware elimină complet suprafața de atac pentru mașinile care pornesc doar de pe disc local.
Izolați rețeaua de boot. Țineți provizionarea într-un VLAN dedicat, limitați ce hosturi pot trimite ICMP către mașinile care pornesc și nu faceți niciodată boot PXE printr-un segment la care pot ajunge dispozitive neverificate.
Monitorizați traficul din timpul pornirii. Mesajele de eroare ICMP supradimensionate îndreptate către clienții PXE și pornirile care se blochează fără explicație sunt semnalele pe care merită să alertați până la actualizarea firmware-ului.
Urmăriți furnizorii. Nu există o soluție oficială de ocolire. Corecția este o modificare simplă de cod, care nu necesită revocarea de certificate sau chei, spre deosebire de BootHole sau BlackLotus, așa că actualizările de BIOS și UEFI de la producători ar trebui să fie mai ușor de implementat odată ce apar. Actualizați pachetele edk2 ale distribuțiilor imediat ce sunt lansate și prioritizați hosturile de virtualizare pe care mașinile virtuale pornesc prin PXE.

O astfel de vulnerabilitate contează doar dacă un atacator poate ajunge efectiv la hosturile care pornesc, iar aceasta este o întrebare despre rețeaua dumneavoastră, nu despre firmware. Un test de penetrare intern realizat de echipa 4tify răspunde direct la ea: care segmente transportă trafic de boot, ce poate vedea o stație compromisă în timpul unei ferestre de provizionare și dacă măsurile de mai sus rezistă în practică.