Fragnesia e i suoi amici: quando le vulnerabilità della page cache continuano a ripresentarsi

Un paio di settimane fa, ho scritto di Copy-Fail (CVE-2026-31431) e di come l'approccio di difesa in profondità di Red Hat OpenShift abbia impedito la fuga dai container nonostante un kernel vulnerabile. Ho cercato attivamente di uscire da un container OpenShift, ho ottenuto l'accesso root all'interno del pod quasi immediatamente, ma non sono comunque riuscito a passare all'host. La vulnerabilità del kernel era reale. Il percorso di exploit era reale. Le difese hanno retto. 

Mentre stavo concludendo questo articolo, un'altra variante correlata, DirtyDecrypt (CVE-2026-31635), ha iniziato a circolare pubblicamente insieme a discussioni sull'exploit e analisi di proof of concept. A quel punto, ci siamo trovati ad esaminare quattro principali vulnerabilità di escalation dei privilegi Linux in circa 14 giorni, tutte basate su varianti dello stesso modello generale.

Questa è per me la parte più importante.

A un certo punto, non si tratta più di CVE isolati. Si inizia a riconoscere un problema sistemico. Sottosistemi diversi. Percorsi di attacco diversi. La modalità alla base è la stessa: manipolare il comportamento di copy-on-write all'interno della page cache del kernel, corrompere file teoricamente immutabili ed eseguire l'escalation dei privilegi.

Se gestisci un'infrastruttura di produzione in questo momento, è una consapevolezza che cambia lo scenario piuttosto rapidamente. Inseguire i singoli CVE uno alla volta non sembra più una strategia di sicurezza, ma piuttosto il tentativo di afferrare dei fiocchi di neve con la lingua durante una valanga. Il risultato finale non è piacevole. 

L'importante è che la tua architettura rimanga resiliente quando, inevitabilmente, comparirà la variante successiva.

Perché, a questo punto, è probabile che si presenti.

CVE diversi, stesso modello

Nelle ultime due settimane, i ricercatori hanno individuato diverse vulnerabilità correlate: Copy-Fail prende di mira la manipolazione generica della page cache, Dirty Frag si sposta nei percorsi ESP/XFRM e RxRPC, Fragnesia punta a ESP-in-TCP e ora DirtyDecrypt emerge pubblicamente in relazione a rxgk. I dettagli dell'implementazione variano, ma la logica di attacco più ampia rimane notevolmente coerente. I ricercatori individuano una debolezza concettuale in un'area del codice di rete del kernel, quindi iniziano a esaminare i sottosistemi adiacenti, alla ricerca di presupposti simili e protezioni mancanti. E ne trovano sempre di più.

Questo modello ricorrente mi preoccupa più di qualsiasi singolo numero CVE.

Ho creato un cluster ROSA e ho deciso di testare Fragnesia direttamente su OpenShift. Il cluster eseguiva OpenShift 4.21.15 su Red Hat Enterprise Linux (RHEL) CoreOS 9.6 con un kernel 5.14.0-570.113.1.el9_6.x86_64 vulnerabile. Il sottosistema vulnerabile era presente. In teoria, l'ambiente avrebbe dovuto essere vulnerabile agli attacchi.

Quello che volevo capire non era semplicemente se il kernel fosse vulnerabile. Lo sapevamo già. Volevo vedere dove la catena di exploit si sarebbe effettivamente interrotta, in presenza di diverse configurazioni di sicurezza.

Innanzitutto, ho distribuito un pod standard con le protezioni predefinite di OpenShift. Niente di speciale. Nessun privilegio elevato. Nessun SCC meno restrittivo. Solo un container Fedora di base che esegue sleep infinity.

La catena di exploit si è interrotta quasi immediatamente.

La creazione dello spazio dei nomi utente è stata bloccata prima che l'attacco potesse fare progressi significativi. Il sottosistema vulnerabile esisteva ancora, ma il container non ha mai acquisito le funzionalità necessarie per raggiungere il percorso del codice pericoloso. I vincoli del contesto di sicurezza (SCC) predefiniti di OpenShift, combinati con l'applicazione di SELinux, hanno chiuso la porta prima che l'attacco iniziasse davvero a muoversi.

Questo non mi ha sorpreso.

Quello che mi interessava di più era lo scenario successivo, il tipo di configurazione che molte organizzazioni reali utilizzano effettivamente.

Ho creato un carico di lavoro utilizzando l'SCC anyuid e ho eseguito in modo esplicito il container come ID utente (UID) 0. Questo è estremamente comune negli ambienti brownfield, un contesto in cui le applicazioni legacy non sono mai state progettate seguendo il concetto del privilegio minimo e le organizzazioni spesso scendono a compromessi perché "l'app ne ha bisogno".

All'interno del pod, avevo i privilegi root.

La catena di exploit è fallita comunque.

Anche con anyuid, SELinux ha continuato ad applicare le restrizioni del dominio container_t, impedendo le operazioni sullo spazio dei nomi necessarie per continuare l'escalation. Questo è l'aspetto che spesso sfugge del modello di OpenShift: i livelli di sicurezza si sovrappongono intenzionalmente. L'allentamento di un controllo non annulla automaticamente il resto del perimetro di sicurezza.

A quel punto ho deciso di smettere di essere cauto.

Ho creato una configurazione volutamente pericolosa con SCC con privilegi, utente root e seccomp senza restrizioni. Questa è la configurazione più permissiva che puoi realisticamente creare per un carico di lavoro OpenShift senza consegnare direttamente l'host.

Alla fine, le cose hanno iniziato a muoversi.

Gli spazi dei nomi utente hanno funzionato. unshare -U ha avuto successo. La catena di exploit ha iniziato a progredire in modi mai consentiti dagli scenari precedenti. Su molte distribuzioni Kubernetes, questo è più o meno il punto in cui si passa dalla "ricerca sulla sicurezza" alla "risposta agli incidenti".

Eppure l'attacco è fallito comunque.

Fragnesia non richiede solo la creazione di uno spazio dei nomi. Richiede una corretta mappatura UID/GID all'interno dello spazio dei nomi affinché l'autore dell'attacco possa ottenere le funzionalità necessarie per accedere ai percorsi di rete vulnerabili.

Quest'ultima fase è stata bloccata.

Anche con SCC privilegiato, root e seccomp senza restrizioni, SELinux ha negato le operazioni di scrittura su /proc/self/uid_map. Senza una mappatura UID corretta, la catena di escalation si è interrotta. L'assenza di privilegi di root nello spazio dei nomi comportava l'impossibilità di accedere a XFRM/ESP. L'assenza di accesso ai sottosistemi impediva la corruzione della cache delle pagine.

Il kernel è rimasto vulnerabile per tutto il tempo, ma l'exploit è comunque fallito. Questa distinzione è fondamentale.

I test hanno confermato una mia convinzione di lunga data: una valida difesa in profondità resta preziosa, soprattutto quando qualcosa va storto. Non quando tutto è configurato alla perfezione. Non quando tutti i carichi di lavoro sono integri e basati sul principio del privilegio minimo, e i team adibiti alla sicurezza ottengono tutto ciò che desiderano. Gli ambienti reali sono complessi. I controlli vengono allentati. Esistono carichi di lavoro obsoleti. Si scende continuamente a compromessi operativi.

Bisogna chiedersi se l'architettura possa reggere ancora, accettando alcuni di questi compromessi.

In questo caso, ha funzionato.

Anche dopo l'indebolimento simultaneo di più livelli di sicurezza, SELinux ha continuato a considerare il container come non attendibile, impedendo la fase finale di escalation dei privilegi necessaria per portare a termine l’attacco.

È questa la differenza tra le "funzionalità di sicurezza" e un'architettura di sicurezza coerente. Questo dibattito più ampio sull'architettura mi sta più a cuore del singolo CVE di Fragnesia. Perché, se le ultime settimane ci hanno insegnato qualcosa, è che probabilmente questa famiglia di vulnerabilità continuerà a evolversi.

La domanda che le organizzazioni devono iniziare a porsi non è più: "abbiamo applicato la patch per CVE-2026-46300?". La vera domanda è: "cosa succede a livello operativo quando martedì prossimo verrà pubblicata la CVE-2026-XXXXX relativa a un altro sottosistema che nessuno stava ancora monitorando?".

L'attacco si evolve. I segnali no.

Siamo realisti: a questo punto, non si tratta più di un'ipotesi.

È proprio qui che Red Hat Advanced Cluster Security for Kubernetes acquisisce molto più valore rispetto a un approccio basato esclusivamente sui CVE. L'aspetto interessante di Red Hat Advanced Cluster Security in questo contesto non è la conoscenza specifica di Fragnesia, ma il fatto che i modelli comportamentali legati a queste catene di exploit siano spesso riconoscibili anche quando la vulnerabilità specifica cambia.

Un container di applicazioni web che crea improvvisamente spazi dei nomi utente è un evento insolito. Un carico di lavoro applicativo che esegue /bin/su è insolito. Questi segnali restano interessanti indipendentemente dal fatto che l'exploit si chiami Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt o con qualunque altro nome troveranno i ricercatori la prossima settimana.

Il CVE cambia, ma in questi casi il comportamento rimane lo stesso.

Questo è importante perché i cicli di divulgazione sono più veloci di quanto molte organizzazioni riescano realisticamente a intervenire, su flotte di grandi dimensioni, senza compromettere la stabilità operativa. L'architettura e la visibilità comportamentale ti fanno guadagnare tempo. A volte questo tempo fa la differenza tra l'esecuzione di un piano di remediation controllato e il passare le 18 ore successive in una sessione di gestione degli incidenti a chiedersi quali cluster siano esposti.

Lo stesso vale a livello operativo su scala di flotta.

Testare tre pod in laboratorio è semplice. Coordinare le modifiche alle policy su decine o centinaia di cluster, mentre i carichi di lavoro di produzione restano online, è un problema del tutto diverso. È qui che Red Hat Advanced Cluster Management for Kubernetes trasforma la situazione: da una corsa ai ripari reattiva a un rollout controllato. Invece di controllare i cluster uno alla volta, identificare le configurazioni pericolose e coordinare le modifiche del profilo di sicurezza tra i team in modo manuale, puoi definire policy coerenti centralmente e distribuirle ovunque in un colpo solo.

Questa distinzione assume un’importanza critica quando compaiono nuove varianti a distanza di pochi giorni.

Sul mio cluster Red Hat OpenShift on AWS (ROSA), il kernel è rimasto vulnerabile per tutto il test. I sottosistemi vulnerabili erano ancora presenti. Tecnicamente, i prerequisiti per l'attacco erano presenti.

La catena di exploit continuava a fallire perché i controlli a più livelli interrompevano l'escalation in diversi punti.

Poi DirtyDecrypt ha iniziato a circolare pubblicamente mentre stavo ancora scrivendo questo articolo.

Stessa logica di attacco più ampia. Sottosistema diverso. Le stesse difese erano già efficaci.

Non è fortuna. È una questione di architettura. Questa è la difesa in profondità.

Scopri di più

• Quando l'IA trova i bug: perché la difesa in profondità è sempre stata la soluzione
• Prova OpenShift gratuitamente
• Scopri di più su OpenShift Platform Plus