CIFSwitch: Bug Kernel Linux Da Root Su CentOS/Rocky

CIFSwitch permette escalation locale a root su multiple distribuzioni Linux. Il PoC è pubblico, la patch upstream disponibile, ma le policy SELinux/AppArmor bl…

Contenuto

CIFSwitch: Bug Kernel Linux Da Root Su CentOS/Rocky
CIFSwitch: Bug Kernel Linux Da Root Su CentOS/Rocky

La vulnerabilità CIFSwitch, resa pubblica il 28 maggio 2026 dal ricercatore Asim Manizada, permette a un utente locale non privilegiato di ottenere privilegi root su una dozzina di distribuzioni Linux server e desktop. Il proof-of-concept è già disponibile su GitHub. La stessa falla, però, è inoffensiva su Fedora, Ubuntu 26.04 LTS e CentOS Stream 10: il confine di sicurezza non è il kernel, ma le policy di contenimento del sistema operativo.

Punti chiave
  • Il kernel Linux accetta key description cifs.spnego da qualsiasi processo userspace, senza verificarne l'origine dal sottosistema CIFS.
  • La default request-key policy esegue cifs.upcall come root con parametri controllabili dall'attaccante, che pivot su un namespace locale e carica un modulo NSS malevolo prima del privilege drop.
  • Linux Mint, CentOS Stream 9, Rocky Linux 9, Kali, AlmaLinux 9.7, SLES 15 SP7 e SLES SAP sono exploitable stock; Fedora 40-44, Ubuntu 26.04, CentOS Stream 10 e openSUSE Tumbleweed sono bloccati di default.
  • Il bug kernel-side risale al 2007. La patch upstream aggiunge un vet_description hook per cifs.spnego. Il CVE è in attesa di assegnazione.

Come funziona l'attacco: il boundary kernel-userspace come superficie

CIFSwitch non è una falla nel client CIFS del kernel in isolamento, ma nella transizione di trust tra kernel e userspace. Quando il kernel monta una share CIFS con autenticazione Kerberos, delega al processo userspace cifs.upcall — fornito dal pacchetto cifs-utils — la gestione dei ticket. Il meccanismo di key description cifs.spnego è il punto di coordinamento.

Secondo la pubblicazione di Manizada riportata da linuxiac.com, il kernel non verifica che le richieste cifs.spnego originino effettivamente dal sottosistema CIFS. Qualsiasi processo userspace può forgiarle. La default request-key policy, tuttavia, esegue comunque cifs.upcall come root, anche quando la description è interamente controllata dall'attaccante. Questo è il nucleo del problema: un boundary confusion che trasforma una richiesta di servizio in una superficie di attacco.

L'exploit imposta upcall_target=app e un pid malevolo. Il helper entra così in un namespace controllato dall'attaccante, dove trova una configurazione NSS localmente piazzata e un modulo libnss_*.so.2 modificato. cifs.upcall carica ed esegue questo codice prima di rilasciare i privilegi root. La fonte descrive il risultato: un modulo NSS malevolo scrive un'entry in /etc/sudoers.d, consegnando all'attaccante accesso root persistente.

"The primitive is reliable and turns any local shell into a path to root" — Saeed Abbasi, Qualys (riguardo a CVE-2026-46333, vulnerabilità distinta da CIFSwitch)

La distribuzione roulette: perché la stessa vulnerabilità colpisce o no

Manizada ha testato oltre quindici distribuzioni. Il risultato è una mappa di exploitabilità frammentata che dipende meno dalla presenza del bug kernel — presente dappertutto dal 2007 — che dalla configurazione di sicurezza di ogni sistema.

Stock-exploitable, cioè vulnerabili out-of-the-box, risultano: Linux Mint 21.3 e 22.3, CentOS Stream 9, Rocky Linux 9, Kali Linux dalle versioni 2021.4 a 2026.1, AlmaLinux 9.7 e AlmaLinux Azure, SLES 15 SP7, SLES SAP 15 SP7, e SLES SAP 16 con SELinux in modalità permissive. Questi sistemi combinano kernel vulnerabile, cifs-utils compatibile — versione 6.14 o successive con backport — e policy di contenimento che non interrompono la catena di esecuzione.

Exploitable solo con cifs-utils installato manualmente: Ubuntu 18.04, 20.04 e 22.04 LTS, Debian 11, 12 e 13, Pop!_OS 22.04 e 24.04, openSUSE Leap 15.6, Rocky Linux 8, Oracle Linux 8 e 9, Amazon Linux 2023. Su queste distribuzioni il pacchetto non è presente di default, ma un utente privilegiato o un processo di deployment può averlo aggiunto.

Bloccati di default: Fedora 40, 41, 42, 43 e 44, Ubuntu 26.04 LTS, CentOS Stream 10, Rocky Linux 10, AlmaLinux 10.1, Oracle Linux 10, openSUSE Tumbleweed e Leap 16.0, SLES 16. Su questi sistemi SELinux o AppArmor interrompono l'esecuzione di cifs.upcall nel contesto modificato, o le user namespace sono configurate in modo da impedire il pivot. La falla kernel c'è, ma il perimetro di contenimento la neutralizza.

Il ruolo di cifs-utils 6.14+ e le condizioni di attivazione

La vulnerabilità richiede la congiunzione di cinque condizioni. La prima è il kernel con il bug del 2007, presente su tutte le versioni interessate al momento della pubblicazione. La seconda è cifs-utils 6.14 o successivi, o versioni con backport del meccanismo upcall_target. La terza è la default cifs.spnego request-key rule, che esegue l'helper come root. La quarta è l'abilitazione di user namespace o mount namespace non privilegiati. La quinta è l'assenza di blocco da parte di SELinux o AppArmor sulla catena di esecuzione.

Cybersecuritynews.com riporta che Manizada ha utilizzato un metodo di discovery assistito da intelligenza artificiale per identificare il percorso di attacco, un dettaglio che sottolinea come le superfici di trust boundary nei sottosistemi storici del kernel siano ora oggetto di analisi automatizzata. Il PoC è pubblico: questo rimuove la barriera tecnica all'exploitation e impone un assessment immediato per gli ambienti multi-tenant, hosting condiviso, container con namespace abilitati, e sistemi con mount CIFS/SMB Kerberos attivi.

Perché è importante

Il dossier non specifica misure correttive dettagliate per singole distribuzioni né una timeline di rilascio delle patch stabili. Il CVE è in attesa di assegnazione. Non emergono evidenze di sfruttamento in-the-wild, ma la pubblicazione del PoC rende la finestra di esposizione misurabile in giorni.

La fonte non documenta il numero esatto di sistemi enterprise con CIFS attivo e cifs-utils installato, né la natura dei dati a rischio in caso di compromissione. La versione precisa del kernel da cui il bug è stato introdotto è indicata genericamente come "2007", senza identificazione di commit o release note. Il CVSS non è disponibile.

La variabilità di exploitabilità per distribuzione è il dato che strutturalmente altera la risposta: non esiste una singola azione universale, ma una verifica individuale delle cinque condizioni di attivazione su ogni sistema. La patch upstream, che aggiunge il vet_description hook, è pubblicata ma non ancora incorporata nei kernel stabili delle distribuzioni stock-exploitable.

Lettura: quando il contenimento supera la correttezza

CIFSwitch inverte la gerarchia abituale della sicurezza Linux. Non è la correttezza del codice kernel — fallata da quasi vent'anni — a determinare l'esito dell'attacco, ma la severità delle policy di contenimento imposte dal sistema operativo. Fedora e le distribuzioni derivate Red Hat più recenti dimostrano che un SELinux aggressivo può neutralizzare un bug kernel locale persistente, mentre le configurazioni permissive o assenti lo lasciano transitare in root senza attrito.

Questo ha implicazioni per gli ambienti containerizzati e cloud, dove le immagini di base spesso ereditano policy minimizzate per compatibilità. Il rischio si concentra dove la convenienza operativa ha allentato il contenimento, non dove il kernel è teoricamente più o meno sicuro. La stessa vulnerabilità, su due sistemi con kernel identico, produce esiti opposti: una distribuzione roulette che rende obbligatoria l'inventariazione delle condizioni locali prima di qualsiasi valutazione del rischio.

Domande frequenti

Perché il bug è rimasto nel kernel dal 2007?
Il meccanismo cifs.spnego è un percorso di trust boundary tra kernel e userspace che non è stato sottoposto a validazione dell'origine delle richieste. La fonte indica il 2007 come anno di introduzione, ma non specifica il commit o le circostanze della mancata revisione.
Un sistema senza mount CIFS è a rischio?
La fonte non elenca condizioni di attivazione alternative a cifs-utils e al mount CIFS/SMB Kerberos. Il sistema non è stock-exploitable se il pacchetto non è installato, ma la vulnerabilità kernel rimane presente.
La patch upstream è sufficiente?
La patch aggiunge il vet_description hook per cifs.spnego, ma il dossier non documenta date di integrazione nei kernel stabili delle singole distribuzioni. L'adozione dipende dai maintainer di ciascun progetto.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews