Dirty Frag colpisce Linux: exploit root pubblico senza patch disponibili

Una nuova catena di vulnerabilità battezzata Dirty Frag sta creando forte preoccupazione tra amministratori Linux, provider cloud e team DevSecOps. Il motivo è che la falla di sicurezza appena scoperta permette a un utente locale senza privilegi di ottenere accesso root su numerose distribuzioni moderne sfruttando un difetto del kernel Linux. Non si tratta del classico exploit instabile che richiede condizioni precise o finestre temporali difficili da replicare. Qui il comportamento è deterministico, con tassi di successo molto elevati e senza kernel panic in caso di errore.

La ricerca arriva da Hyunwoo Kim, noto online come @v4bel, già coinvolto in studi precedenti su vulnerabilità kernel della famiglia “Dirty“. Il lavoro nasce come estensione concettuale delle tecniche viste in Dirty Pipe e nella più recente Copy Fail, che già ha scatenato non poca preoccupazione ed è attivamente sfruttata dagli aggressori. In tutti questi casi il punto critico riguarda la manipolazione della page cache del kernel: una zona di memoria che Linux utilizza per accelerare l’accesso ai file.

Dirty Frag (repository GitHub) alza ulteriormente il livello di rischio: l’attacco combina infatti due vulnerabilità distinte presenti in sottosistemi differenti del networking Linux, la xfrm-ESP Page-Cache Write e la RxRPC Page-Cache Write. La prima esiste dal 2017, la seconda dal 2023. In pratica, la superficie vulnerabile copre quasi un decennio di sviluppo del kernel.

Rottura dell’embargo e assenza di patch correttive su Linux

Il problema ha già colpito distribuzioni come Ubuntu 24.04.4, Fedora 44, AlmaLinux 10, RHEL 10.1, CentOS Stream 10 e openSUSE Tumbleweed. La situazione si complica ulteriormente perché al momento della divulgazione pubblica non sono disponibili patch ufficiali né identificativi CVE assegnati.

Il ricercatore Hyunwoo Kim ha spiegato che la divulgazione anticipata dei dettagli sul problema di sicurezza (rottura dell’embargo) è avvenuta dopo consultazioni con i maintainer attraverso la mailing list linux-distros@openwall.org, lasciando intendere che le informazioni tecniche stessero già circolando fuori dal perimetro riservato: non esiste però ancora una ricostruzione pubblica completa.

Qualcuno avrebbe diffuso dettagli, patch parziali o indicatori sufficienti a rendere inevitabile la pubblicazione. Non sono stati indicati responsabili specifici e al momento non esistono conferme ufficiali su chi abbia materialmente compromesso l’embargo. Il risultato però è stato immediato: exploit pubblico disponibile mentre le distribuzioni Linux non hanno ancora preparato aggiornamenti correttivi completi.

Perché Dirty Frag è diverso dalle classiche vulnerabilità Linux

Molte vulnerabilità di privilege escalation dipendono da race condition: l’attaccante deve sincronizzare eventi kernel con estrema precisione per corrompere la memoria od ottenere uno stato incoerente. Dirty Frag segue una strada diversa: il bug nasce da una logica errata nella gestione dei frammenti associati alle strutture sk_buff, utilizzate dal networking stack Linux.

Il problema principale è che il kernel modifica pagine della cache collegate ai file aperti in sola lettura senza applicare correttamente il meccanismo di copy-on-write, che dovrebbe creare una copia separata della memoria prima di ogni modifica. Un attaccante può sfruttare funzioni apposite per collegare direttamente le pagine della cache ai buffer utilizzati dalla rete.

Durante la gestione dei pacchetti di rete, alcune parti del kernel elaborano direttamente le pagine di memoria condivise. L’aggressore può quindi alterare il contenuto in memoria  correlato a file “sensibili”, come /usr/bin/su o /etc/passwd, anche senza avere permessi di scrittura sul filesystem.

Il risultato è notevole: il file su disco resta formalmente intatto, ma la copia mantenuta in RAM dalla page cache contiene codice o dati modificati. Qualunque processo che leggerà successivamente quel file userà la versione corrotta presente in memoria.

Un bug semplice ma difficile da rilevare

Dirty Frag dimostra ancora una volta quanto sia delicata la gestione della memoria condivisa nel kernel Linux: la vulnerabilità sfrutta percorsi perfettamente legittimi del networking stack che interagiscono in modo errato con il sottosistema della page cache.

Dal punto di vista difensivo la situazione è scomoda perché molti strumenti EDR (Endpoint Detection and Response) tradizionali cercano comportamenti tipici delle race condition o crash del kernel anomali. Il bug descritto da Hyunwoo Kim può invece far apparire le operazioni svolte come quasi normali.

Inoltre la presenza di exploit pubblici immediatamente funzionanti aumenta il rischio operativo: il proof-of-concept rilasciato porta allo sfruttamento di Dirty Frag con una singola riga di comando. Bastano accessi shell limitati su server condivisi, container host o piattaforme CI/CD per tentare l’escalation locale.

Mitigazioni temporanee e limiti operativi

Al momento della divulgazione pubblica non risultano disponibili patch ufficiali complete né aggiornamenti che coinvolgano le varie distribuzioni. I maintainer hanno suggerito una mitigazione drastica, almeno per adesso: bloccare il caricamento dei moduli vulnerabili.

Il comando consigliato crea un file in /etc/modprobe.d/dirtyfrag.conf e impedisce il caricamento di esp4, esp6 e rxrpc. Successivamente rimuove i moduli già caricati tramite rmmod. La mitigazione riduce l’esposizione ma introduce effetti collaterali: disabilitare ESP (Encapsulating Security Payload), il protocollo responsabile della cifratura e della protezione del traffico di rete, su Linux significa interrompere alcune configurazioni VPN basate su IPsec. In infrastrutture aziendali o data center con tunnel IPsec attivi, questa modifica può avere conseguenze significative sul funzionamento delle comunicazioni sicure. In pratica bisogna valutare rapidamente il compromesso tra disponibilità dei servizi e rischio di privilege escalation locale.

Un’altra osservazione importante: le mitigazioni pubblicate per Copy Fail non proteggono da Dirty Frag: le due vulnerabilità condividono parte della logica ma colpiscono sottosistemi differenti.

Gli amministratori Linux sono chiamati a monitorare bene gli advisory pubblicati da ciascuna distribuzione, verificare la presenza dei moduli coinvolti e limitare quanto possibile accessi shell. Dirty Frag non richiede exploit complessi o tecniche “esotiche”: è proprio questo il suo aspetto più pericoloso.