In questo articolo Indice dei contenuti 2 sezioni
Una vulnerabilità critica nel firmware UEFI, rimasta nascosta nel codice per circa 16 anni, mette a rischio numerosi server impiegati nei data center, nelle infrastrutture aziendali e nei servizi cloud. La falla ha ricevuto un punteggio CVSS di 9,5 su 10 e consente a un aggressore di eseguire codice malevolo durante l’avvio della macchina, quindi prima che il sistema operativo possa attivare le proprie difese.
Il problema riguarda TianoCore EDK II, implementazione open source delle specifiche UEFI usata come base da molti produttori di firmware come AMI, Insyde e Phoenix. Anche Project Mu, la versione di EDK II sviluppata e rafforzata da Microsoft, ha utilizzato il componente coinvolto. Proprio questa diffusione rende la faccenda delicata perché un errore in una libreria condivisa può finire nei prodotti di aziende diverse e restarci per anni. Nel 2023 LogoFail aveva mostrato come il caricamento di immagini nel firmware potesse aprire la strada a codice non autorizzato e poco dopo PixieFail aveva messo in luce difetti nell’avvio via rete. Stavolta si tratta di un bug ancora più vecchio che tocca di nuovo le funzioni di rete. La gravità è alta ma non tutti i server sono esposti e il semplice collegamento a Internet non basta per subire un attacco.
Il driver PXE e il messaggio ICMP che corrompe la memoria
Il componente incriminato è NetworkPkg/UefiPxeBcDxe, un driver che implementa parte delle funzioni PXE (Preboot Execution Environment), la tecnologia che permette a un computer di avviarsi sfruttando risorse in rete invece di affidarsi solo a un’unità locale. Grazie a PXE gli amministratori distribuiscono sistemi operativi, reinstallano server e preparano nuove macchine senza intervenire fisicamente su ognuna. In genere il client ottiene via DHCP i dati di configurazione, scarica un programma di avvio tramite TFTP e prosegue con il caricamento dell’ambiente richiesto.
Il driver gestisce anche alcuni messaggi ICMP, usati dai protocolli IP per segnalare errori e condizioni particolari. Secondo l’avviso ufficiale di TianoCore chi riesce a raggiungere il client con un messaggio ICMP costruito ad arte può corrompere la memoria e in certe condizioni eseguire codice arbitrario. Alla radice c’è un classico buffer overflow aggravato da un errore nel calcolo degli offset. Le informazioni sugli errori finiscono in un campo chiamato Mode.IcmpError con capacità fissa di 504 byte, ma le due funzioni dedicate a IPv4 e IPv6 non rispettano correttamente questo limite.
Gli scenari possibili sono almeno due. Nel primo il pacchetto malevolo rovina i dati interni del driver e provoca un’eccezione del processore che blocca l’avvio o impedisce un ripristino. Il secondo è molto più serio perché un attaccante che conosce bene la versione del firmware e la disposizione delle sue strutture in memoria può alterare il comportamento della macchina. TianoCore descrive la possibilità di eseguire istruzioni con privilegi equivalenti al ring 0 dell’architettura x86, il livello normalmente riservato al kernel. Tutto accade prima che antivirus, strumenti EDR e protezioni del kernel entrino in funzione.
Perché Secure Boot e TPM non bastano e chi rischia davvero
Secure Boot si basa su una catena di fiducia fatta di firme digitali e chiavi autorizzate, mentre il chip TPM con il measured boot registra misurazioni crittografiche di alcune parti della sequenza di avvio. Qui però viene sfruttato un difetto in un driver legittimo già in esecuzione, magari incluso in un’immagine UEFI firmata, che reagisce in modo imprevisto a dati esterni malevoli. Secure Boot non può quindi fermare direttamente l’overflow e le misurazioni TPM non garantiscono di accorgersi in tempo di una manipolazione temporanea della memoria. HD Moore, creatore di Metasploit e oggi responsabile della ricerca presso Dragos, ha evidenziato anche il possibile coinvolgimento di dati sensibili e delle protezioni della cifratura del disco.
Non esiste ancora un elenco pubblico dei server vulnerabili. Perché una macchina sia attaccabile il firmware deve contenere il componente difettoso, deve essere in corso la procedura PXE interessata e l’aggressore deve far arrivare il messaggio ICMP proprio in quella finestra di tempo. Firewall, segmentazione e filtri ICMP possono impedirlo. Causare un blocco poi non significa riuscire con la stessa facilità a eseguire codice e Jesse Michael di Eclypsium ha osservato che un exploit affidabile deve tenere conto della specifica versione del firmware, compresi gli indirizzi delle strutture in memoria. Intel ha fatto sapere che nessuno dei suoi prodotti commerciali ancora supportati risulta coinvolto, precisando però che i produttori di schede madri possono integrare autonomamente il codice vulnerabile, mentre Arm ha indicato che il problema non riguarda direttamente il proprio portafoglio.
Fonte: TecnoAndroid