EDK2 UEFI: vulnerabilitatea CVE-2026-97631 în boot-ul PXE

A devenit publică o vulnerabilitate critică, CVE-2026-97631 (scor 9.5 din 10), în TianoCore EDK II (EDK2), codul open source de referință cu care producătorii de hardware și furnizorii cloud construiesc firmware-ul UEFI care pornește serverele. Problema se află în driverul care gestionează pornirea din rețea (PXE) și permite rularea de cod înainte ca sistemul de operare să se încarce și înainte ca Secure Boot să verifice vreo componentă.

Sursele analizate sunt Ars Technica (republicat integral de Wired) și Security Affairs, care citează avizul oficial al proiectului; de la The Hacker News avem doar titlul, care confirmă punctele principale.

O dezvăluire venită prea devreme

Vulnerabilitatea a fost descoperită de cercetători de la Anthropic și Google, care conveniseră o dezvăluire coordonată pentru ianuarie. Potrivit Ars Technica, în septembrie AMI a publicat un pull request care descria defectul și conținea corecția; când cercetătorii au observat, proiectul TianoCore a difuzat avizul public. Cu patch-ul la vedere, reconstruirea mecanismului de atac devine mult mai simplă pentru cine are competențele necesare, iar distribuirea actualizărilor de firmware pe milioane de mașini va dura.

Detalii tehnice

Defectul are aproximativ 16 ani și se află în driverul PXE Base Code (NetworkPkg/UefiPxeBcDxe). În timpul pornirii din rețea, driverul ține deschisă o recepție pentru mesajele ICMP de eroare și copiază fiecare mesaj într-un câmp fix de 504 octeți, Mode.IcmpError. Potrivit avizului, în handlerele IPv4 și IPv6 (PxeBcIcmpErrorDpcHandle și PxeBcIcmp6ErrorDpcHandle) verificarea limitelor este greșită:

• un mesaj mai lung de 504 octeți este copiat oricum;
• pointerul de destinație avansează cu lungimea cumulată, nu cu cea a fragmentului;
• nicio verificare anterioară nu limitează lungimea mesajului.

Rezultatul este o scriere de octeți aleși de atacator dincolo de câmp, în memoria fazei DXE a firmware-ului. Avizul clasifică problema drept Out-of-bounds Write, Classic Buffer Overflow și Incorrect Calculation of Buffer Size, cu impact asupra confidențialității, integrității și disponibilității.

Cum se exploatează

• Mesajul malițios este un simplu unicast către adresa IP a dispozitivului, trimis în timp ce pornirea PXE este în curs, pe IPv4 sau IPv6, fără autentificare.
• Cu date invalide, pornirea se blochează (DoS).
• Cunoscând build-ul exact al firmware-ului, atacatorul își poate rula propriul cod în mediul UEFI, în ring 0, ocolind și atestarea care ar trebui să demonstreze serverelor la distanță că mașina este intactă.
• Codul nu este persistent, dar poate servi la instalarea altor componente care rulează la fiecare pornire.

HD Moore (Dragos), citat de Ars Technica, observă că în acel moment procesul de pornire are încă acces la componente precum TPM: cu un acces scurt la rețea sau cu un dispozitiv furat, s-ar putea ajunge la spargerea criptării discului.

Limitele

• Este nevoie de un anumit control asupra rețelei locale: este un scenariu pentru insideri sau atacatori deja intrați, care vor să își ridice privilegiile. Sursele sunt de acord că nu există dovezi că vulnerabilitatea poate servi drept acces inițial.
• Potrivit lui Jesse Michael (Eclypsium), exploit-ul trebuie adaptat fiecărui model, fiecărei versiuni și configurații, pentru că adresele de memorie se schimbă.
• Nicio sursă nu semnalează exploit-uri publice sau exploatare în curs.

Ca tehnici MITRE ATT&CK relevante (clasificarea noastră) se pot indica T1542 Pre-OS Boot (în special T1542.001, System Firmware) și T1068 Exploitation for Privilege Escalation.

Cine este afectat

Sunt expuse sistemele cu firmware bazat pe EDK2 care pornesc din rețea prin PXE, funcție care, potrivit Ars Technica, este activată implicit. Nu sunt afectate dispozitivele de acasă și din birourile mici, nici cine pornește doar de pe disc.

Perimetrul exact nu este încă clar:

• AMI, Insyde și Phoenix folosesc pe scară largă EDK2, iar și Project Mu de la Microsoft conținea componenta vulnerabilă;
• Intel declară că niciunul dintre produsele sale comerciale aflate încă în suport de securitate nu este cunoscut ca afectat, dar că un producător de plăci sau de sisteme poate să fi integrat funcția;
• Arm afirmă că CVE-ul „nu este direct aplicabil” produselor sale;
• AMD, Phoenix, AMI, Microsoft și Amazon nu răspunseseră la întrebările Ars Technica în momentul publicării.

Sursele nu vorbesc despre mașini virtuale: multe platforme de virtualizare folosesc firmware UEFI derivat din EDK2, așa că merită să întrebi și furnizorii de hipervizoare și cloud dacă mașinile virtuale care pornesc din rețea sunt implicate.

Impactul pentru companiile europene și italiene

Pornirea PXE este obișnuită în centrele de date, în provizionarea automată a serverelor și în distribuirea imaginilor de sistem. Pentru entitățile NIS2, în special furnizorii de servicii digitale, centrele de date și furnizorii cloud, vulnerabilitatea intră în gestionarea vulnerabilităților și în securitatea lanțului de aprovizionare: e nevoie de un inventar al firmware-ului și de o cerere formală către furnizori. În sănătate, unde serverele și stațiile de lucru sunt adesea pregătite din rețea, trebuie verificate și mediile de provizionare. Având în vedere răspândirea codului, HD Moore consideră probabil ca vulnerabilitatea să rămână mult timp în sistemele fără suport.

Ce faci acum

1. Fă inventarul sistemelor care pornesc din rețea și al firmware-ului lor (producător, model, versiune BIOS/UEFI).
2. Întreabă producătorii de servere și de firmware dacă sunt afectați și când va sosi actualizarea. Potrivit Eclypsium, corecția este o actualizare BIOS/UEFI obișnuită: nu sunt necesare revocări sau actualizări ale cheilor Secure Boot (PK, KEK, db, dbx).
3. Dezactivează pornirea PXE acolo unde nu e necesară, cel puțin temporar, așa cum sugerează sursele.
4. Acolo unde e necesară, izolează rețelele de provizionare în segmente dedicate și limitează cine poate trimite trafic către mașinile aflate în pornire (recomandarea noastră generală).
5. Păstrează active TPM și Secure Boot: rămân utile, chiar dacă nu opresc acest atac.
6. Verifică logurile de rețea pentru încercări de exploatare, de exemplu mesaje ICMP de eroare neobișnuit de lungi sau fragmentate către mașini în pornire PXE.

Cum ajută ARXDOME

ARX Sentry colectează inventarul hardware și de sistem al mașinilor cu agent, un punct de plecare pentru a afla ce servere trebuie verificate cu producătorii. ARX Watch ascultă rețeaua prin sondele deja instalate și arată și dispozitivele fără agent, util ca să nu uiți mașini din segmentele de provizionare. Logurile firewall-urilor colectate de ARX Sentry ajung în paginile SOC, unde poți examina evenimentele care privesc aceste segmente.

Ultima actualizare: 28 octombrie 2026