Nelle ultime settimane, il mondo Linux è stato scosso da una nuova vulnerabilità che, per molti amministratori, è stata la goccia che ha fatto traboccare il vaso in una serie di falle critiche del kernel. Stiamo parlando di Fragnesia, un exploit locale di escalation dei privilegi che si aggiunge alla famiglia dei fallimenti noti Errore di copia y Profumo sporcoe ciò consente a qualsiasi utente non privilegiato di ottenere l'accesso root con un singolo comando su sistemi vulnerabili.
Dopo Copy Fail e Dirty Frag, Fragnesia arriva in un momento di vera e propria stanchezza da patch: aggiornamenti urgenti, riavvii a catena e soluzioni di emergenza. Tuttavia, ignorarla non è un'opzione. La vulnerabilità interessa diverse distribuzioni Linux e versioni del kernel.Esiste già una prova di concetto pubblica e pienamente funzionante. In questo articolo, analizzeremo cos'è Fragnesia, come funziona l'attacco, quali distribuzioni sono interessate, quali patch e misure di mitigazione esistono e come verificare se il proprio sistema è protetto.
Cos'è Fragnesia e perché è correlata a Dirty Frag e Copy Fail?
Fragnesia è una nuovo exploit di escalation dei privilegi locali (LPE) Si tratta di una vulnerabilità del kernel Linux che rientra nella stessa famiglia di vulnerabilità di Copy Fail (CVE-2026-31431) e Dirty Frag (nota anche come Copy Fail 2, CVE-2026-43284). Condivide con queste l'idea di base: sfruttare falle logiche nello stack di rete e nella gestione della memoria del kernel per ottenere una primitiva di scrittura in memoria che consente di modificare file teoricamente di sola lettura e, in ultima analisi, di eseguire codice con privilegi di root.
La sentenza è stata soprannominata Fragnesia e tracciato come CVE-2026-46300con un punteggio CVSS di 7,8. La vulnerabilità è stata scoperta da William Bowling del team di sicurezza V12. Poco dopo, Sam James ha annunciato il problema sulla mailing list OSS Security, chiarendo che non si trattava di una semplice rianalisi di Dirty Frag, ma di un bug diverso sulla stessa superficie funzionale del kernel.
In termini pratici, Fragnesia è la Terzo guasto critico di questo tipo in sole due settimaneCopy Fail, Dirty Frag e ora Fragnesia. Tutti e tre sfruttano problemi di gestione dei dati del kernel per corrompere la cache delle pagine di file critici come /usr/bin/suFragnesia raggiunge questo obiettivo attraverso un'altra via: il sottosistema ESP-in-TCP di XFRM.
Dettagli tecnici: il sottosistema XFRM ESP-in-TCP e il guasto logico
Il nucleo di Fragnesia risiede in un Errore logico nel sottosistema Linux XFRM ESP-in-TCPNello specifico, nel percorso ULP (Upper Layer Protocol) denominato espintcp. XFRM è il framework del kernel responsabile, tra le altre cose, dell'elaborazione del traffico IPsec, ed ESP (Encapsulating Security Payload) è il protocollo che garantisce riservatezza e autenticità tramite crittografia (ad esempio, AES-GCM), come accaduto con una vulnerabilità nel protocollo di rete CAN BCM.
L'attacco si basa su una situazione del kernel molto specifica: quando un socket TCP passa alla modalità ESP-in-TCP dopo che le pagine del file sono state aggiunte alla sua coda di ricezione da chiamate come splice(2) o sendfile(2)Anziché trattare questi dati come semplici pagine di un file, il kernel li interpreta come testo cifrato ESP e applica la "decrittografia", modificando così le pagine della cache in loco.
Come conseguenza di questo errore, il kernel inietta il flusso di chiavi AES-GCM su pagine della cache corrispondenti ai file di sola letturaCiò si traduce in scritture arbitrarie di byte nella cache di pagina. Controllando il IV (nonce) e altri parametri, un utente non privilegiato può indirizzare con precisione queste scritture. Il risultato è una primitiva di scrittura deterministica che consente di modificare un numero controllato di byte in qualsiasi file leggibile, anche se il file system lo contrassegna come immutabile o di sola lettura.
La dimostrazione pubblica del concetto si concentra su modificare il binario /usr/bin/su nella cache della paginaInietta uno stub ELF di 192 byte (indipendente dalla posizione) nella copia in memoria di quel binario. Da quel momento in poi, la prossima volta che viene eseguito suLo stub verrà eseguito con privilegi di root, garantendo un'arrampicata immediata senza bisogno di run condizionali o altri trucchi aggiuntivi.
Misure di mitigazione temporanee: come proteggersi se non è possibile riavviare
Sebbene sia consigliato Installa un kernel patchato e riavvia il sistema il prima possibile.Sono state descritte efficaci soluzioni temporanee per coloro che non possono permettersi un riavvio immediato. La buona notizia è che, poiché Fragnesia sfrutta gli stessi moduli base (esp4, esp6 e, facoltativamente, rxrpc) di Dirty Frag, la soluzione proposta per quest'ultimo funziona anche per Fragnesia.
La tecnica consiste in bloccare il caricamento dei moduli vulnerabili configurando modprobe e, se sono già caricati, scaricali dalla memoria. Questo viene fatto scrivendo una regola in /etc/modprobe.d/ che sostituisce il caricamento di tali moduli con comandi innocui (come /bin/falsePoi si invoca rmmod riguardo a loro, ignorando silenziosamente gli errori se non sono presenti.
In distribuzioni come CloudLinux, il comando proposto per Dirty Frag (che funziona altrettanto bene per Fragnesia) genera un file dirtyfrag.conf con regole per esp4, esp6 y rxrpcTenta inoltre di scaricare i moduli attivi. Se hai già applicato questa mitigazione per Dirty Frag, Non devi fare altro per Fragenesis fino a quando non installerai il kernel corretto, perché anche la superficie di attacco sarà neutralizzata.
È importante considerare la compatibilità: esp4 ed esp6 sono le trasformazioni del kernel per IPsecLa loro disabilitazione interrompe i tunnel IPsec che dipendono dal percorso dati del kernel (ad esempio, strongSwan o Libreswan). Si raccomanda di non utilizzare questa mitigazione sugli host che terminano o instradano il traffico IPsec critico. Il modulo rxrpc Si tratta del protocollo di trasporto AF_RXRPC, utilizzato quasi esclusivamente dai client AFS, e raramente presente sui server web o in altri scenari di utilizzo generico.
Ripristina la cache della pagina dopo aver applicato la mitigazione
Un altro aspetto spesso trascurato è che l'exploit, quando funziona, può lasciare qualcosa in memoria. copie modificate di file binari legittimi nella cache di paginaL'esempio più tipico è /usr/bin/suTuttavia, altri file binari privilegiati potrebbero essere compromessi se l'attaccante decidesse di cambiare obiettivo.
Pertanto, alcuni avvisi raccomandano che, dopo aver applicato la mitigazione della blacklist dei moduli, si proceda a svuotare la cache di pagina del sistema per forzare un ricaricamento pulito dal disco. Ciò può essere ottenuto scrivendo su /proc/sys/vm/drop_caches Un valore che indica al kernel di rilasciare la cache delle pagine e i dentries/inodes. Questa operazione rimuove solo le pagine pulite, quindi è sicura nei sistemi di produzione, sebbene possa causare un aumento temporaneo dell'I/O del disco quando i file binari e i dati vengono letti nuovamente.
L'idea è semplice: se un'istanza di Fragnesia era già stata eseguita prima della mitigazione, Le pagine danneggiate vengono scartate e verrà riutilizzata la versione non modificata presente sul disco.In combinazione con la blacklist dei moduli, questo passaggio riduce il rischio che un'eventuale modifica residua nella cache possa ancora essere sfruttata o causare comportamenti anomali nel sistema.
Stato delle patch e raccomandazioni dei fornitori
La maggior parte dei principali attori dell'ecosistema Linux ha reagito rapidamente alla scoperta di Fragnesia. Distribuzioni come AlmaLinux e CloudLinux hanno kernel modificati pubblicati o in fase di finalizzazioneRed Hat ha indicato di star valutando in che misura le misure di mitigazione esistenti per le vulnerabilità precedenti coprano anche la CVE-2026-46300.
Diversi fornitori di sicurezza, tra cui aziende associate a Google e Microsoft, hanno pubblicato analisi che spiegano che La vulnerabilità consente ad aggressori locali non privilegiati di modificare il contenuto dei file di sola lettura nella cache di pagina. e possono raggiungere i privilegi di root tramite corruzione deterministica della memoria. Wiz, ad esempio, sottolinea che AppArmor e le restrizioni sugli spazi dei nomi utente non privilegiati possono mitigare parzialmente l'impatto, richiedendo tecniche aggiuntive per sfruttare con successo il bug in alcuni ambienti.
Microsoft, da parte sua, sottolinea che Al momento della loro dichiarazione non si osservava alcuno sfruttamento attivo in natura.Tuttavia, raccomandano comunque agli utenti di applicare la patch non appena disponibile, utilizzando i normali strumenti di aggiornamento. Qualora l'applicazione immediata della patch non sia possibile, consigliano di adottare le stesse misure di mitigazione proposte per Dirty Frag: disabilitare esp4, esp6 e le funzionalità non essenziali relative a IPsec/XFRM, rafforzare la sicurezza dell'accesso locale interattivo e intensificare il monitoraggio di attività anomale di escalation dei privilegi.
Contesto della minaccia: mercato degli exploit e stanchezza da patch
La scoperta di Fragnesia avviene in un contesto in cui Lo sfruttamento delle vulnerabilità di escalation locale in Linux sta acquisendo valore sul mercato nero.Recenti segnalazioni descrivono un utente, con lo pseudonimo di "berz0k", che offre una vulnerabilità zero-day di escalation locale in Linux per 170.000 dollari, presumibilmente funzionante su diverse distribuzioni. Secondo ThreatMon, il venditore afferma che la vulnerabilità è di tipo TOCTOU (Time-of-Check Time-of-Use), consente un'escalation stabile senza causare crash e utilizza un payload sotto forma di libreria condivisa..so) distribuito in /tmp.
Tutto ciò alimenta la sensazione di saturazione e affaticamento Molti amministratori stanno esprimendo la loro frustrazione: "Un'altra vulnerabilità della stessa categoria di Dirty Frag", oppure "Altre otto di questo tipo e me ne vado", commenti a metà tra il serio e il faceto. La realtà è che la successione delle vulnerabilità Copy Fail, Dirty Frag e Fragnesia sta costringendo i team di sistema a ripensare la propria strategia di aggiornamento del kernel, soprattutto in ambienti in cui i riavvii frequenti sono molto costosi.
In questo contesto, le soluzioni di live patching come KernelCare o meccanismi simili stanno acquisendo importanza come alternativa per applicare correzioni critiche senza interrompere i serviziNel frattempo, le distribuzioni sono sotto pressione per ridurre il più possibile il tempo che intercorre tra la scoperta del problema, il rilascio della correzione a monte e la disponibilità del pacchetto corretto nei repository stabili.
In definitiva, Fragenesis è diventato un caso di studio su come un piccolo pezzo di logica in un sottosistema specializzato come XFRM ESP-in-TCP può avere conseguenze devastanti se combinate con meccanismi di caching delle pagine e binari privilegiatiRimanere aggiornati sugli avvisi di sicurezza, le mailing list, i blog di distribuzione e i canali di comunicazione come Mattermost o X (precedentemente Twitter) è fondamentale per reagire rapidamente e ridurre al minimo il periodo di esposizione.
La minaccia rappresentata da Fragnesia non risiede solo nella sua capacità di concedere l'accesso root con un singolo comando, ma anche nel fatto che dimostra la misura in cui i moderni ambienti Linux dipendono da un Una complessa catena di fiducia che si estende dal codice del kernel agli strumenti di aggiornamento e alle politiche di protezione.La protezione implica la combinazione di patch ufficiali, misure di mitigazione ben consolidate, soluzioni di livepatch laddove opportuno e una chiara politica di controllo degli accessi e monitoraggio a livello locale, in modo che un guasto di questo tipo non diventi il singolo punto di vulnerabilità per l'intera infrastruttura.
