Il firmware è il buco nelle patch di cui nessuno si occupa, e il nuovo bug UEFI lo dimostra

Il tuo EDR è eccellente, l'hypervisor è aggiornato, le immagini dei container sono state ricostruite ieri sera. Allora chi applica le patch al codice che gira prima che tutto questo esista?

È la domanda scomoda dietro CVE-2026-97631, una falla critica in TianoCore EDK II, il codice di riferimento open source usato dalla maggior parte dei produttori di firmware UEFI. Secondo i riassunti dell'inchiesta di Ars Technica, si trova in un componente ICMP, nel percorso di avvio da rete, e ha un punteggio di 9,5 su 10. Permette a un attaccante di eseguire codice durante l'avvio, prima che protezioni come Secure Boot e il TPM possano stabilire una catena di fiducia.

Alcuni dettagli contano. Stando a quanto riportato, i payload non persistono da soli, ma possono installare altro codice che gira a ogni avvio successivo. La falla è inoltre diventata pubblica prima di una divulgazione prevista per gennaio, secondo un riepilogo di FourWeekMBA su Ars. E Jesse Michael di Eclypsium ha detto ad Ars che la correzione passa dall'installazione di un aggiornamento del BIOS/UEFI.

«La maggior parte dei server della Terra» è un titolo, non una misura

Prima di tutto, un po' di prudenza. Il titolo dice che la falla minaccia la maggior parte dei server del pianeta. Come sottolinea Tech Insider, la copertura afferma che il codice di riferimento è usato dalla maggior parte dei produttori di server al mondo, ma non fornisce né un numero di macchine colpite né una percentuale. Codice condiviso non significa esposizione condivisa. Build e configurazioni dei produttori probabilmente differiscono, e il fatto che una macchina sia raggiungibile attraverso quel percorso di avvio da rete dipende verosimilmente dalla configurazione.

Pensiamo che questa sfumatura valga in entrambi i sensi. Significa che non devi riavviare nel panico tutta la flotta stanotte. Significa anche che non puoi conoscere la tua esposizione da un titolo, e sospettiamo che molte organizzazioni non sappiano rispondere nemmeno con i propri registri. Questa è la vera notizia.

Il bug è nuovo; la filiera rotta è vecchia

Guarda come viaggia una correzione del firmware. Nella copertura di Ars del 2024 di una precedente ondata di bug UEFI, la catena era descritta con chiarezza: i produttori di firmware inviano aggiornamenti ai loro clienti, e questi rendono disponibili le patch ai propri clienti, di solito gli utenti finali. Ogni passaggio è un'azienda diversa e, a nostro avviso, nessuno possiede l'intero percorso.

Confrontalo con un bug in una libreria. Quando di recente è emersa una falla in Brotli, Google e Node.js hanno rilasciato correzioni il 21 ottobre e Microsoft ha seguito con un aggiornamento di emergenza di.NET nel fine settimana, secondo TechRadar. Anche questo è stato disordinato: le copie incluse nei pacchetti fanno sì che aggiornare solo la libreria di Google non protegga ogni app. Ma almeno la correzione passa da canali che la maggior parte dei team sa già gestire, come gli aggiornamenti dei pacchetti e i nuovi rilasci. Il firmware non offre una routine del genere. Devi scoprire quale immagine di quale fornitore usi, aspettare che l'OEM la riconfezioni, programmare una finestra di manutenzione e aggiornare il firmware di macchine che nessuno vuole riavviare.

Poi c'è il livello in cui di solito chi difende individuerebbe un problema. Il codice pre-boot gira sotto il sistema operativo, quindi gli strumenti su cui si affida la maggior parte dei team potrebbero avere poca visibilità. Il firmware ha anche avuto qualche mese difficile. A settembre Cybernews ha segnalato un bypass di Secure Boot tramite la UEFI Shell, riconosciuto da AMI, Gigabyte, Insyde e Cisco, con probabilmente molti altri produttori coinvolti. Due incidenti in due mesi non fanno una tendenza da soli, ma indicano un punto debole.

Tratta il firmware come un prodotto con un responsabile

Il nostro verdetto è semplice: se il firmware non ha un responsabile nel tuo team, hai già deciso di applicare le patch in ritardo. La soluzione è soprattutto di processo, non di strumenti.

• Fanne l'inventario. Devi sapere quale versione di firmware e quale build di quale fornitore c'è su ogni server. Senza, rispondere a «siamo coinvolti?» richiede giorni invece di minuti.
• Nomina un responsabile. Qualcuno dovrebbe seguire gli avvisi dei fornitori e avere l'autorità di programmare le finestre di manutenzione, come un team si occupa del ritmo delle patch del sistema operativo.
• Riduci la superficie raggiungibile. Se su una macchina non ti serve l'avvio da rete, disattivarlo può essere una mitigazione economica. Non possiamo promettere che copra ogni configurazione, quindi controlla cosa dice il tuo fornitore.
• Prova l'aggiornamento. Un aggiornamento del BIOS mai provato sul tuo hardware è una scommessa nel momento in cui conta.

Anche i fornitori hanno i compiti a casa. Un codice di riferimento condiviso in tutto il settore dovrebbe avere un modo condiviso e prevedibile per far arrivare le correzioni ai clienti. Finché non esiste, il peso ricade sugli amministratori: non è giusto, ma è la realtà.

Di questa CVE non si ricorderà il punteggio. La domanda da porsi è quanto tempo servirebbe alla tua organizzazione per sapere quali macchine sono esposte. Se la risposta sincera è «dovremmo scoprirlo», il firmware è il tuo buco nelle patch, e nessun altro lo chiuderà.