CIFSwitch espone Linux a escalation local root tramite CIFS e cifs-utils

CIFSwitch introduce un nuovo caso di local privilege escalation su Linux che non colpisce universalmente tutti i sistemi, ma diventa estremamente rilevante negli ambienti in cui sono presenti cifs-utils, user namespaces abilitati e configurazioni che consentono l’interazione tra il client CIFS del kernel e l’helper userspace cifs.upcall. La vulnerabilità, scoperta dal ricercatore Asim Viladi Oglu Manizada, permette a un utente locale non privilegiato di ottenere privilegi root sfruttando una chain logica tra request_key, descrizioni cifs.spnego, namespace switching e lookup NSS. Il bug non nasce da una classica corruzione di memoria, ma da una fiducia implicita tra componenti kernel e helper eseguiti con privilegi elevati. La divulgazione del 27 maggio 2026 e la disponibilità di un PoC pubblico su GitHub rendono urgente la mitigazione per amministratori di sistema, distribuzioni enterprise e workstation Linux multiutente. Il caso colpisce distribuzioni come Linux Mint, Kali Linux, Rocky Linux, AlmaLinux e CentOS Stream quando le condizioni richieste sono presenti, e conferma come le interazioni tra kernel, userspace e moduli di autenticazione possano generare catene di exploit sofisticate anche senza vulnerabilità memory safety.

CIFSwitch nasce dall’interazione tra kernel CIFS e cifs.upcall

La chain CIFSwitch sfrutta l’interazione tra il client CIFS del kernel Linux e l’helper userspace cifs.upcall, incluso nel pacchetto cifs-utils. Il client CIFS usa chiavi SPNEGO per gestire l’autenticazione Kerberos in scenari di mount o accesso a risorse di rete, mentre il sistema request-key può invocare automaticamente helper userspace quando una chiave necessaria non è disponibile. La configurazione predefinita in /etc/request-key.d/cifs.spnego.conf consente l’esecuzione di cifs.upcall come root, perché l’helper deve recuperare materiale di autenticazione e risolvere contesti utente. Il problema nasce quando un processo non privilegiato riesce a forgiare una descrizione di chiave cifs.spnego e a invocare request_key. Il kernel accetta la descrizione senza validarne correttamente l’origine perché il tipo di chiave cifs.spnego non disponeva del hook .vet_description. Questo permette all’attaccante di consegnare a cifs.upcall una descrizione controllata, contenente campi come pid, uid, creduid e upcall_target=app. A quel punto l’helper root interpreta quei parametri e avvia una sequenza che può portare allo switch nei namespace controllati dall’attaccante prima dell’esecuzione di lookup sensibili. La vulnerabilità è quindi una chain di fiducia rotta: il kernel accetta una descrizione non verificata, l’helper privilegiato la considera valida e il sistema di risoluzione utenti carica componenti controllati dall’attaccante.

Il forging della chiave cifs.spnego apre la catena di exploit

Il primo passaggio tecnico dell’attacco consiste nel forging della descrizione cifs.spnego. L’attaccante locale costruisce una stringa artificiale con parametri arbitrari, poi usa request_key per farla trattare come richiesta legittima dal kernel. Poiché la funzione di descrizione associata al tipo di chiave non verifica in modo sufficiente l’origine della richiesta, il kernel passa la stringa all’helper cifs.upcall. Questo comportamento è centrale perché sposta dati controllati da un utente non privilegiato dentro un processo eseguito con privilegi root. La presenza di upcall_target=app forza l’helper a seguire un percorso specifico che include switch_to_process_ns sul pid indicato nella descrizione. Se quel processo appartiene a un ambiente predisposto dall’attaccante, lo switch porta l’helper dentro user namespace e mount namespace controllati. Il punto critico è temporale e semantico: lo switch avviene prima che l’helper esegua determinate operazioni di lookup e prima che il contesto venga reso sicuro. CIFSwitch non deve rompere una protezione di memoria, non deve corrompere stack o heap e non deve sfruttare race complesse nel senso tradizionale. Gli basta manipolare la descrizione della chiave e guidare un helper privilegiato dentro un contesto filesystem e namespace preparato. Questo rende la vulnerabilità interessante per la sicurezza Linux perché mostra come bug puramente logici possano generare un impatto equivalente a un exploit root tradizionale.

Namespace confusion e NSS lookup completano l’escalation a root

La fase decisiva della chain avviene dopo lo switch di namespace. Una volta entrato nel contesto controllato dall’attaccante, cifs.upcall esegue getpwuid(uid) per recuperare informazioni sull’utente e sul gruppo associato. Questa chiamata passa attraverso il sistema Name Service Switch, che legge configurazioni come nsswitch.conf e carica moduli NSS per risolvere utenti, gruppi e altre informazioni di sistema. CIFSwitch sfrutta il fatto che, nel mount namespace predisposto dall’attaccante, il percorso di risoluzione può puntare a una configurazione malevola e a una libreria controllata, per esempio libnss_pwn.so.2. Quando getpwuid viene eseguito dal processo privilegiato, il modulo NSS malevolo viene caricato ed eseguito con privilegi root. Da qui l’attaccante ottiene esecuzione arbitraria elevata. Il PoC dimostra l’impatto scrivendo un file in /etc/sudoers.d che concede all’utente privilegi sudo senza password, ma la stessa primitiva potrebbe essere usata per creare backdoor persistenti, modificare configurazioni di sistema, aggiungere utenti privilegiati o installare componenti malevoli. La forza dell’attacco sta nella combinazione tra namespace confusion e meccanismi legittimi di risoluzione dinamica. Il sistema non viene violato tramite exploit classici contro memoria o syscall pericolose, ma tramite un percorso perfettamente plausibile in cui un helper root entra nel namespace sbagliato e carica codice dal contesto sbagliato.

La scoperta con LLM e graph-based reasoning mostra un nuovo metodo di ricerca

La scoperta di CIFSwitch da parte di Asim Viladi Oglu Manizada è rilevante anche per il metodo utilizzato. Il ricercatore ha impiegato strumenti basati su LLM e ragionamento graph-based per esplorare relazioni multihop tra oggetti di sicurezza del kernel, helper userspace, configurazioni request-key, namespace e meccanismi NSS. Questa metodologia consente di comporre catene che difficilmente emergono da un’analisi lineare del codice, perché ogni singolo componente può apparire ragionevole se osservato isolatamente. Il bug esisteva dal 2007, ma è rimasto nascosto proprio perché richiede di collegare concetti distribuiti tra kernel e userspace: il tipo di chiave cifs.spnego, la mancanza di .vet_description, il comportamento di cifs.upcall, lo switch nei namespace, la semantica di getpwuid e il caricamento dinamico dei moduli NSS. Gli LLM, combinati con un modello a grafo delle relazioni di sicurezza, possono accelerare l’identificazione di percorsi di exploit non ovvi, soprattutto nei sistemi Linux dove molte superfici dipendono da interazioni storiche tra componenti modulari. CIFSwitch non dimostra che l’AI sostituisce il ricercatore, ma mostra che può amplificare la capacità di trovare catene logiche lunghe, dove il valore non sta nel singolo bug ma nella sequenza di fiducia mal posizionata tra più livelli del sistema.

La patch del kernel valida le descrizioni SPNEGO e chiude il vettore

La correzione principale arriva nel kernel con il commit 3da1fdf4efbc490041eb4f836bf596201203f8f2, che aggiunge il metodo .vet_description al tipo di chiave cifs.spnego. Questo cambiamento consente al kernel di verificare le credenziali SPNEGO prima di accettare la descrizione, impedendo che una stringa controllata da un utente non privilegiato venga trattata come input legittimo per l’helper root. L’aggiornamento del kernel rappresenta quindi la mitigazione strutturale, perché elimina la premessa della chain. Gli amministratori devono applicare gli update distribuiti dai rispettivi vendor e verificare la presenza di backport nelle release enterprise. Dove l’aggiornamento immediato non è possibile, esistono mitigazioni temporanee. Se il protocollo CIFS con Kerberos non è necessario, è possibile bloccare o rimuovere il modulo CIFS e disinstallare cifs-utils. In alternativa, si può sovrascrivere la regola request-key in /etc/request-key.d/cifs.spnego.conf per negare automaticamente le richieste cifs.spnego tramite keyctl negate, riducendo la possibilità di invocare cifs.upcall. Un’ulteriore difesa consiste nel disabilitare la creazione di user namespaces non privilegiati tramite sysctl, misura già adottata in diversi ambienti hardening per limitare molte catene di local privilege escalation. Policy SELinux o AppArmor restrittive possono inoltre ridurre l’impatto impedendo il caricamento o l’esecuzione di componenti malevoli da percorsi controllati.

Le distribuzioni vulnerabili dipendono da cifs-utils e user namespaces

CIFSwitch viene definita una vulnerabilità non universale perché non basta eseguire Linux per essere vulnerabili. Servono condizioni specifiche: cifs-utils installato, versione 6.14 o superiore in molti scenari descritti, configurazione request-key attiva per cifs.spnego, possibilità di creare user namespaces non privilegiati e assenza di policy SELinux o AppArmor sufficientemente restrittive. Le distribuzioni citate tra quelle esposte includono Linux Mint, Kali Linux, Rocky Linux, AlmaLinux, CentOS Stream e altre derivate o basate su stack simili, ma l’impatto reale dipende dalla configurazione del sistema.

Nota per la sicurezza: La criticità maggiore risiede nei sistemi (CentOS, Rocky, AlmaLinux) in cui l’exploit ha successo anche con SELinux in modalità “enforcing”, aggirando di fatto le policy di sicurezza obbligatorie (MAC).

I server che non usano CIFS, che non hanno cifs-utils, che disabilitano gli user namespace o che applicano policy MAC restrittive possono non essere sfruttabili nel percorso dimostrato dal PoC. Gli amministratori devono quindi evitare sia l’allarmismo generico sia la sottovalutazione. La verifica corretta passa dall’inventario: presenza del pacchetto cifs-utils, esistenza di /etc/request-key.d/cifs.spnego.conf, abilitazione degli unprivileged user namespaces, disponibilità del modulo CIFS, stato delle policy di confinamento e versione del kernel. In ambienti multiutente, desktop condivisi, server di laboratorio, sistemi di sviluppo, infrastrutture universitarie e workstation con account locali multipli, il rischio aumenta perché un utente senza privilegi può tentare l’escalation verso root.

Gli amministratori devono trattare CIFSwitch come rischio locale ad alta priorità

Le conseguenze pratiche di CIFSwitch sono concrete perché un attaccante locale può ottenere root in pochi secondi quando le condizioni sono presenti. Questo tipo di vulnerabilità è particolarmente importante in ambienti multiutente, server condivisi, workstation aziendali, laboratori, sistemi di sviluppo e infrastrutture dove un accesso shell limitato può essere ottenuto tramite credenziali deboli, account compromessi o servizi applicativi esposti. Una volta raggiunto root, l’attaccante può installare backdoor, modificare sudoers, disabilitare logging, estrarre segreti, accedere a dati di altri utenti e consolidare la persistenza. Il fatto che la vulnerabilità non sia remota non la rende marginale, perché molte intrusioni moderne seguono un percorso a due fasi: compromissione iniziale con privilegi limitati, poi escalation locale per prendere il controllo completo del sistema. Il PoC pubblico su GitHub accelera sia la validazione delle mitigazioni sia la possibilità di weaponization da parte di attori opportunisti. Gli amministratori devono quindi aggiornare rapidamente il kernel, ridurre la superficie CIFS se non necessaria, controllare request-key, limitare user namespaces, verificare regole SELinux/AppArmor e cercare segni di compromissione come file inattesi in /etc/sudoers.d, moduli NSS sospetti, modifiche a nsswitch.conf, librerie libnss_*.so.2 non autorizzate e attività anomale di cifs.upcall. CIFSwitch dimostra che le dipendenze userspace installate “per comodità” possono diventare parte di una catena root quando interagiscono con meccanismi kernel privilegiati.

CIFSwitch conferma la pericolosità dei bug logici kernel-userspace

CIFSwitch entra tra le vulnerabilità Linux più interessanti non per universalità, ma per eleganza e profondità tecnica della chain. La falla dimostra che i bug logici nell’interazione tra kernel e userspace possono essere potenti quanto gli exploit di memoria, soprattutto quando attraversano helper eseguiti come root, sistemi di richiesta chiavi, namespace e meccanismi dinamici come NSS. La patch con .vet_description risolve il punto di ingresso, ma il caso lascia una lezione più ampia: ogni passaggio in cui il kernel passa input a un helper privilegiato deve avere validazioni rigorose sull’origine, sul contesto e sulla semantica dei dati. La ricerca basata su LLM e grafi di dipendenze mostra inoltre una direzione promettente per l’analisi di sistemi complessi, perché molte vulnerabilità moderne non sono nel singolo file sorgente ma nella composizione di componenti storici. Per gli sviluppatori Linux, CIFSwitch rafforza la necessità di audit sulle interfacce kernel-userspace e sugli helper privilegiati. Per gli amministratori, impone un principio operativo chiaro: ridurre funzionalità non necessarie, aggiornare rapidamente, confinare gli helper e trattare ogni meccanismo automatico eseguito come root come una superficie di attacco.