Negli ambienti Linux – spesso celebrati come roccaforti della sicurezza – c’è una notizia che dovrebbe far sobbalzare chiunque lavori seriamente nella cyber security: è stata scoperta una vulnerabilità critica nel componente Shim, uno dei pilastri su cui poggia il meccanismo di avvio sicuro (Secure Boot) di moltissime distribuzioni Linux.

Una falla che, se sfruttata, permette di aggirare completamente le difese del sistema prima ancora che il kernel venga caricato. Un attacco che si insinua nel momento più vulnerabile della catena di fiducia: l’accensione.

I dettagli della vulnerabilità critica nel boot Linux

La vulnerabilità è stata catalogata come CVE‑2023‑40547 ed è stata scoperta da un team di ricercatori che ha analizzato il comportamento del parser HTTP integrato in Shim, il bootloader firmato da Microsoft ma utilizzato per far partire in sicurezza sistemi operativi Linux su piattaforme UEFI.

Il problema, in sintesi brutale, è un’errata gestione della memoria durante la fase di caricamento via rete (HTTP Boot): il modulo effettua una copia dei dati che può portare a una scrittura oltre i limiti del buffer – classicone delle vulnerabilità, ma qui con impatti che definire gravi è un eufemismo.

Con una mossa ben studiata, un attore malevolo potrebbe sfruttare questa falla per eseguire codice arbitrario prima che il sistema operativo entri in gioco. E quando dico “arbitrario”, intendo proprio che può infilare un bootkit – persistente, silenzioso e pressoché invisibile alle soluzioni di sicurezza tradizionali – dentro il cuore del sistema.

Parliamo di un tipo di attacco che non si limita a compromettere un’applicazione o una libreria, ma che si installa letteralmente prima di tutto, in una posizione dalla quale può falsificare, mascherare o neutralizzare qualsiasi tentativo di rilevamento da parte di antivirus, EDR o qualsiasi altro strumento che opera a livello del sistema operativo.

Sono affette tutte le principali distro Linux

Il problema è trasversale: tutte le principali distribuzioni Linux che hanno usato Shim negli ultimi dieci anni ne sono affette. E non parliamo solo di sistemi desktop o server, ma anche di infrastrutture cloud, ambienti embedded, edge computing, e perfino apparati IoT industriali che adottano soluzioni Linux custom.

La falla apre una finestra d’attacco che attraversa ambienti critici, dove la sicurezza dell’avvio è un pilastro strategico.

E allora ecco che la questione si fa sistemica: non è solo un bug, è un campanello d’allarme sulla fiducia cieca che spesso viene riposta nei meccanismi di Secure Boot, e più in generale nella filiera di avvio dei sistemi. Una fiducia che, in questo caso, si rivela mal riposta.

Il paradosso è amaro: proprio ciò che dovrebbe garantire l’integrità dell’avvio può diventare il cavallo di Troia che permette l’infiltrazione.

E qui non parliamo di un attacco teorico.

La condizione è sfruttabile da remoto in contesti di rete (PXE, boot via HTTP), ma anche in presenza di accesso locale con privilegi elevati – un rischio tutt’altro che raro in ambienti misti, condivisi o cloud-based.

Le contromisure da adottare

Dal punto di vista delle contromisure, le principali distribuzioni Linux si sono già mosse: è stata rilasciata una nuova versione di Shim (la 15.8), che corregge non solo questa falla ma anche altre cinque vulnerabilità correlate.

È stata, inoltre, aggiornata la DBX, la revocation list di Secure Boot che consente di invalidare i binari vulnerabili.

Ma qui arriva il vero nodo: aggiornare Shim non basta, bisogna anche assicurarsi che il firmware del sistema carichi la nuova DBX, cosa che avviene solo se l’utente – o l’amministratore – aggiorna il firmware UEFI o utilizza strumenti specifici come fwupdmgr.

Cosa che, diciamocelo, non tutti fanno. Soprattutto in ambienti dove la manutenzione firmware è l’ultima ruota del carro.

Serve un cambio di paradigma nella cyber security

E allora torniamo al punto focale: la catena di fiducia. L’illusione che un sistema con Secure Boot attivo sia per definizione “al sicuro” deve cadere.

Come professionisti della sicurezza, dobbiamo cambiare paradigma: smettere di trattare il boot come una scatola nera inviolabile e iniziare a testare, validare, monitorare attivamente anche i componenti prima del kernel.

Questo include analisi delle firme, controllo delle DBX, uso di TPM e Remote Attestation, e una politica seria di gestione delle patch – anche quelle del firmware.

Non basta abilitare una spunta per essere al sicuro

Questa vulnerabilità non è solo una falla tecnica, è uno schiaffo culturale. Ci ricorda che non basta “abilitare una spunta” per essere al sicuro. Che non esistono scorciatoie nella sicurezza informatica. E che ogni anello della catena, incluso quello più basso e apparentemente “intoccabile”, può diventare il punto d’ingresso di un attacco.

In tempi in cui si parla tanto di zero trust, questa vicenda ci mette davanti a un’idea ancora più radicale: zero fiducia anche nel bootloader.

E forse è proprio da lì che deve ripartire la sicurezza dei sistemi del futuro.