In questo articolo Indice dei contenuti 2 sezioni
Una grave vulnerabilità nel firmware UEFI mette a rischio buona parte dei server del pianeta. I responsabili della sicurezza di tutto il mondo sono costretti a una nuova corsa contro il tempo. Il difetto ha una gravità di 9,5 su 10 e si trova in TianoCore EDK II, la base di codice open source che produttori di hardware e fornitori cloud usano per creare il firmware attivo durante l’avvio delle macchine. Praticamente tutti i fornitori UEFI, tra cui AMI, Insyde e Phoenix, attingono a piene mani da questo codice di riferimento. Lo stesso vale per Project Mu, la versione rafforzata di EDK2 sviluppata da Microsoft.
Catalogata come CVE 2026 97631, la falla è un problema di corruzione della memoria in un componente ICMP. Permette di eseguire codice malevolo prima che sistema operativo e firmware attivino le loro difese. Tra queste c’è Secure Boot, il meccanismo che stabilisce una catena di fiducia per tutto il codice caricato all’avvio, compreso il TPM. I payload consegnati sfruttando il bug non sono persistenti e girano una sola volta. Possono però aprire la strada all’installazione di altro codice capace di attivarsi a ogni accensione.
Una divulgazione andata storta
A scoprire il problema sono stati Alex Matrosov di Anthropic e Dan Holmes di Google. I due avevano concordato di mantenerlo riservato fino a una divulgazione coordinata prevista per gennaio. Il mese scorso però AMI ha pubblicato una richiesta di modifica con i dettagli della vulnerabilità e la relativa correzione. Quando la cosa è arrivata all’attenzione degli scopritori, i membri del progetto TianoCore hanno diffuso un avviso pubblico la settimana scorsa. Ora la patch è visibile a chiunque e per gli hacker più esperti diventa semplice capire come innescare il difetto e costruire exploit funzionanti. Aggiornare il firmware di milioni di dispositivi venduti da migliaia di produttori resta poi un lavoro lento e macchinoso. La notizia arriva sei giorni dopo un altro caso di divulgazione gestita male, legato a una falla critica nel linguaggio PHP.
Nel dettaglio si tratta di un buffer overflow vecchio di 16 anni nel driver PXE Base Code. È il componente che consente a server e apparati di storage di avviarsi con codice scaricato dalla rete locale. Durante questa fase il driver resta in ascolto dei messaggi di errore ICMP e li copia in un campo fisso da 504 byte, senza però rispettare quel limite. Un insider malintenzionato o un attaccante con accesso alla rete locale può quindi inviare un messaggio troppo lungo che sovrascrive i dati adiacenti. Secondo HD Moore, creatore di Metasploit e responsabile della ricerca di Dragos, chi punta a un server vicino potrebbe dirottare il flusso del programma quando l’avvio ha ancora accesso al TPM. In questo modo arriverebbe persino a violare la cifratura del disco. Il codice malevolo gira in ring 0, il livello più privilegiato della CPU, e aggira i processi di attestazione che dovrebbero certificare l’integrità dell’hardware.
Un bug destinato a durare
La falla si aggiunge a una lunga serie di problemi simili come LogoFail, PixieFail, PKFail, BootHole e BlackLotus. Proprio dopo PixieFail, anch’esso legato all’avvio PXE in EDK2, erano partiti diversi progetti di fuzzing. Evidentemente quelle ricerche non hanno individuato questo difetto. Moore ritiene probabile che si tratti di un bug “eterno”, destinato a sopravvivere nei sistemi non più supportati.
Esistono comunque limiti importanti. Serve un certo controllo sulla rete locale e non ci sono prove che la falla possa offrire un accesso iniziale. Jesse Michael di Eclypsium spiega che l’attaccante deve indovinare indirizzi specifici, quindi l’exploit va adattato a ogni modello, versione e configurazione. A differenza di BootHole o BlackLotus la soluzione è una semplice correzione del codice tramite aggiornamento del BIOS, senza revoche né gestione delle chiavi. Restano esclusi gli utenti domestici e i piccoli uffici che avviano i computer dal disco. Il rischio riguarda le organizzazioni che usano l’avvio da rete con firmware basato su EDK2 e funzione PXE attiva, che è abilitata di default.
Intel ha dichiarato che nessuno dei suoi prodotti commerciali ancora supportati risulta coinvolto. L’azienda ammette però che i produttori di schede potrebbero integrare la funzione vulnerabile. Arm sostiene che la falla non si applica direttamente al suo portafoglio, anche se entrambe le aziende fanno ampio uso di EDK2. AMD, Phoenix Technologies, AMI, Microsoft e Amazon non hanno risposto alle domande. Nessuna risposta è arrivata nemmeno dai rappresentanti del progetto TianoCore.
Fonte: TecnoAndroid