Una vulnerabilità rimasta sepolta per quasi diciannove anni dentro il kernel Linux ha riacceso i riflettori su un angolo poco frequentato del sistema operativo: il dialogo tra i componenti del kernel e gli strumenti in user space che gestiscono l’autenticazione delle condivisioni SMB. Il difetto, battezzato CIFSwitch, consente a un utente locale senza privilegi amministrativi di arrivare fino all’accesso root su parecchie distribuzioni, almeno in determinate condizioni. La scoperta cade in un periodo in cui le falle di elevazione dei privilegi individuate nel kernel continuano a moltiplicarsi, e questo sta spingendo distributori e amministratori a stringere i tempi sull’adozione delle patch.
Come lavora l’autenticazione CIFS dietro le condivisioni
Per capire dove sta il problema bisogna guardare a come funziona l’autenticazione CIFS. Quando un sistema Linux monta una condivisione SMB che usa meccanismi avanzati come Kerberos e SPNEGO, il kernel chiede di generare una chiave di autenticazione chiamata cifs.spnego. La richiesta viaggia attraverso il meccanismo requestkey, che fa parte dell’infrastruttura keyring del kernel stesso.
Se la chiave non c’è, il kernel passa la palla a un programma esterno che appartiene al pacchetto cifs-utils. Il processo cifs.upcall gira con privilegi root e riceve una descrizione zeppa di informazioni: identificativo utente, PID del processo che ha fatto la richiesta, cache delle credenziali Kerberos e i relativi namespace. In condizioni normali questi dati servono al programma per muoversi nell’ambiente giusto e recuperare le credenziali necessarie all’autenticazione.
L’errore che spalanca la porta ai privilegi root
Qui sta il punto debole. Il kernel non controlla a dovere da dove arrivino le richieste cifs.spnego. Tradotto: un utente locale può chiamare direttamente requestkey e costruirsi a mano una descrizione della chiave riempita di parametri a piacere. Senza quei controlli, l’aggressore aggira il percorso CIFS pensato dagli sviluppatori e passa a cifs.upcall dei valori manipolati ad arte.
Quando il programma, che ricordiamo gira come root, interpreta quei dati, finisce per entrare nei namespace indicati dal PID che ha scelto l’attaccante. Il risultato è bello tosto: un componente privilegiato che si ritrova a operare dentro un ambiente controllato da chi ha messo in piedi l’attacco, e da lì all’esecuzione di codice con pieni privilegi amministrativi il passo è breve.
Distribuzioni coinvolte, patch e contromisure
L’impatto di questa vulnerabilità Linux cambia parecchio da una distribuzione all’altra. Alcune sono vulnerabili già nelle configurazioni predefinite, perché si portano dietro cifs-utils già installato e lasciano libera tutta la catena di sfruttamento. Tra quelle segnalate ci sono Linux Mint, CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux e SLES 15 SP7.
Altre risultano esposte solo dopo un’installazione manuale di cifs-utils, oppure quando certe impostazioni di sicurezza permettono l’uso dei namespace non privilegiati. Fedora, molte versioni di Ubuntu, openSUSE, Oracle Linux e altre adottano invece politiche che spezzano il percorso d’attacco. In tanti casi entrano in gioco SELinux o AppArmor, che bloccano alcune delle operazioni indispensabili per portare a termine lo sfruttamento. È un buon promemoria sul valore dell’hardening: non cancella il difetto nel codice, ma può evitare che una falla teoricamente critica si trasformi in una compromissione vera del sistema.
Le principali distribuzioni hanno già cominciato a distribuire gli aggiornamenti correttivi. La soluzione aggiunge verifiche sull’origine delle richieste cifs.spnego, accettando soltanto quelle che arrivano dal percorso CIFS legittimo. In parallelo sono arrivati controlli aggiuntivi lato user space, per confermare che le descrizioni delle chiavi vengano davvero dal kernel e non da processi qualunque.
