S3 1 Tio
S3 1 Tio
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

CIFSwitch, nouvelle faille d’élévation de privilèges dans Linux

Hard times

CIFSwitch, nouvelle faille d’élévation de privilèges dans Linux

Illustration : Flock

Une importante faille de sécurité a été découverte dans Linux par un ingénieur en sécurité de chez SpaceX. Exploitée, elle permet d’obtenir les droits root sur un compte local. Elle résidait dans le noyau depuis 2007.

La faille CIFSwitch fait parler d’elle depuis quelques jours. Découverte par Asim Viladi Oglu Manizada, ingénieur en sécurité chez SpaceX, elle a fait l’objet d’un billet détaillé par ce dernier le 27 mai. On peut notamment y lire qu’elle a été introduite en 2007 et réside à l’intersection du module CIFS (Common Internet File System) dans le noyau et d’un code en espace utilisateur.

Une absence de vérification

L’ingénieur explique que CIFS/SMB est un protocole de fichiers réseau de type Windows et est utilisé pour le montage de ressources distantes. La partie dans le noyau sert ainsi à monter le partage, communiquer avec le serveur, gérer les lectures et écritures, etc. Dans le cas de ressources protégées par Kerberos, le composant noyau fait cependant appel à un assistant (helper) en espace utilisateur fourni par cifs-utils.

C’est là que survient le problème. Quand un partage réseau nécessite une authentification Kerberos, le noyau demande une clé de type cifs.spnego. À ce moment, un composant disposant des droits root, cifs.upcall, est chargé de récupérer les informations d’identification pour que la requête d’une clé se poursuive. Malheureusement, rien n’empêche un utilisateur malintentionné et sans privilège de lancer la même requête avec des informations fabriquées de toutes pièces.

La fausse description peut ainsi introduire un identifiant PID contrôlé par le pirate. Or, le mécanisme de fourniture de la clé ne rejette pas les descriptions fournies par du code en espace utilisateur : elles sont traitées comme si elles venaient du noyau. Résultat, une belle faille de sécurité de type élévation de privilèges. Estampillée CVE-2026-46243, elle échappe de justesse à la qualification « critique » avec un score CVSS de 7,8.

Une dangerosité variable

Sa dangerosité réelle est difficile à exprimer, car elle dépend fortement des configurations. Il faut ainsi un noyau vulnérable, une version vulnérable de cifs-utils, ainsi que, au choix, un espace de noms utilisateur non privilégié ou une politique SELinux/AppArmor ne bloquant pas l’attaque.

Sur les distributions Ubuntu 18.04 à 24.04, Debian 11 à 13, openSUSE Leap 15.6 ou Oracle Linux 8 ou 9 notamment, si cifs-utils est installé, la configuration est vulnérable par défaut. Pour d’autres, comme Linux Mint (21.3 / 22.3), CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux (versions 2021.4 à 2026.1) et SUSE Linux Enterprise Server 15 SP7, cifs-utils est installé par défaut, rendant ces distributions vulnérables.

Les correctifs sont en cours de distribution ou le seront très prochainement. Indépendamment du correctif, il est recommandé de vérifier si le protocole CIFS/SMB est installé et, s’il ne sert pas, de le supprimer. Cela fait plusieurs fois en quelques semaines que des failles d’élévation de privilèges sont détectées dans Linux.

Commentaires (28)

votre avatar
cifs-utils, c'est pour SMBv1, non? SMBv2 et plus utilisent le package samba, de mémoire...
votre avatar
Je n'en ai pas l'impression :
Ce paquet fournit des utilitaires pour gérer les montages des systèmes de fichiers en réseaux CIFS.
votre avatar
Il me semble que c'est juste qu'ils n'ont pas renommé mais par défaut, cifs-utils contient les outils pour faire du CIFS (ce qui est vieux) comme du SMB3 (ce qui est récent).

Par exemple, la page de mount.smb3 indique bien l'utilitaire est fourni par cifs-utils sur Debian:
https://manpages.debian.org/bullseye/cifs-utils/mount.smb3.8.en.html
votre avatar
je viens de le virer, mes partages samba fonctionnent toujours, même sans cifs-utils, donc isokay
votre avatar
Sujet d'appoint :
Et si nous profitions de l'occasion afin d'encourager les utilisateurs à partager les fichiers différemment que via ces volumes montés & ces protocoles privateurs ?
votre avatar
Tu proposes quoi qu'on fasse tous du NFSv4 sur nos réseaux locaux ? Tu as déjà configurer un partage NFS ?
votre avatar
Moi oui, j'utilise que ça et c'est assez facile 👍
(après, je ne saurai dire si c'est du v4 ou une autre version).
votre avatar
Moi je ne fais que ça. Le jour où j'ai dû faire du SMB, j'ai réellement galéré. NFS est tellement plus simple et intuitif.
votre avatar
Si tu as un BON tutoriel sur la mise en place du NFS et en particulier le mapping des users id entre clients et serveurs, je suis preneur. En tout cas, pour moi, un NFS sérieux, c'est tout sauf intuitif. Ou alors seulement si on traite les droits des fichiers en mode "tout à 777".
votre avatar
Et c'est une galère absolue dès que tu as plein de personne qui vienne se connecter de manière intermittente. Pour une connexion permanente à un NAS c'est très bien. Pour que ta cousine dépose ses photos de vacances, c'est juste pas possible.
votre avatar
Ah c'est sûr, le FS de NFS c'est pour File System, donc pour monter en local des volumes distants…
Pour des connexions occasionnelles, du SFTP ça fait très bien l'affaire.
votre avatar
le FS de CIFS veut lui aussi dire File System. SFTP pour déposer des photos avec des néophytes, bonne chance.
votre avatar
Protocole privateur ? Tu as vérifié ? Inventé par IBM en 1983. Implémenté par Microsoft en 1996, qui a poussé sa standardisation. Les versions suivantes ont été documentées.
votre avatar
Est-ce que "protocole utilisé exclusivement par un certain environnement privateur, implicite donc à son utilisation" serait un compromis qui te conviendrait ?
Pas que ça ne change quoi que ce soit sur le fond du problème, à savoir qu'on se le farcit à cause d'une hégémonie M$-ienne… Ergotons, puisque cela dessert l'intérêt général.
votre avatar
Bof, moi je ne me le farcis pas, je trouve ça pratique et fonctionnel sur un réseau local domestique. Ça fonctionne très bien sous Linux, même mieux que sous Windows, et même sans faire de mount. On peut interroger les ressources disponibles, encore un truc qui marche bien mieux sous Linux. Ca se configure aussi très bien sous Linux alors que sous Windows il faut connaître les paramètres planqués à changer si on veut l'utiliser sans authentification. C'est supporté partout,

NFS c'est très bien pour des partages fixes entre machines fixes Linux avec des droits d'accès type Unix. Dès que ça devient dynamique, avec des machines qui vont et viennent, ou qu'il y a autre chose que des machines fixes Linux, ou qu'on ne veut pas d'authentification et de droits d'accès par utilisateur, ça ne va plus.

FTP est mort depuis qu'il a disparu des navigateurs, et on ne pouvait pas écrire de toute façon sans logiciel spécifique. Reste Webdav que je n'ai pas testé, pareil il faut un logiciel spécifique, mais c'est déjà plus usité de nos jours, je n'ai pas d'avis dessus.
votre avatar
FTP est mort depuis qu'il a disparu des navigateurs
Absolument pas !
Je l'utilise tous les jours (enfin en SFTP).
Un bon navigateur de fichier sait faire ça très bien (et c'est bien plus logique que d'utiliser un navigateur web qui est plutôt fait pour afficher des pages html que des arborescences de dossiers et des fichiers).
votre avatar
Attention, SFTP n'est pas du FTP. Je ne parle pas des aspects sécurisations, mais bien sur le fait que le SFTP est un protocole distinct de FTP (malgré la ressemblance du nom et bien que ressemblant sur certains aspects). Ce n'est pas simplement du FTP over SSH.

Certaines fonctionnalités de FTP ne sont d'ailleurs pas dispo à ma connaissance avec SFTP (notion de FTP passif/actif, échange direct de fichiers entre une machine A et une machine B depuis une machine C (sans que les données ne passent pas la machine C), etc.).

D'ailleurs, SFTP ne nécessite pas un serveur FTP pour fonctionner, mais un serveur SSH.
votre avatar
notion de FTP passif/actif
J'espère que tu ne me contrediras pas ici si je dis "bon débarras"...
D'ailleurs, SFTP ne nécessite pas un serveur FTP pour fonctionner, mais un serveur SSH.
Exactement ce que j'en comprends : SFTP est un SCP amélioré et non un FTP sécurisé.
votre avatar
J'ai fait du SMBv2|v3 > NFSv2|v3|v4
Ouf, j en suis parti !
Go to webdav !

Perso, j'utilise à outrance rclone en inter serveurs via systemd :
ExecStart=/usr/bin/rclone serve webdav --vfs-refresh --min-tls-version "tls1.2" --dir-perms (pas de 777!!) --addr IP:port /path/

Après, pour de l'utilisateur final, soit le client de n'est pour ou le web, selon usage/besoin
Si c est 100% synchronisation de fichiers, faut regarder du côté de seafile/syncthing and co
votre avatar
$ sudo apt purge cifs-utils
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Le paquet « cifs-utils » n'est pas installé, et ne peut donc être supprimé
Comme aucun W$ à l'horizon (depuis 15 ans) plus besoin de cette faille !
votre avatar
J'en ai encore, malheureusement ...
votre avatar
@Vincent_H roh je viens de voir que tu étais de retour. Bon retour alors :)
votre avatar
:smack:
votre avatar
Avec toutes ces failles découvertes récemment, quel est le risque pour un utilisateur lambda (moi par exemple avec un Bazzite KDE connecté à Internet) ? Faut-il se déconnecter ? Mettre à jour le système ? Autre ? ou pire, retourner sous Windows ?
votre avatar
Si c'est dans un cadre privé et tu es le seul utilisateur de ta machine, le risque est faible vu que la plupart de ces failles nécessitent un compte local sur la machine. Reste à respecter des règles de base comme ne jamais lancer des scripts sans savoir ce qu'il vont faire, ou encore désactiver les services d'accès distant (genre sshd) si pas utilisés.
votre avatar
ne jamais lancer des scripts sans savoir ce qu'il vont faire
Pas gagné avec cette manie de vendre du curl yolo.sh | sudo bash :craint:
votre avatar
La majorité des failles détectés sont des élévations local de privilège, il faut que l'attaquant ai déjà un accès non privilégier à la machine. Ce qui pour un utilisateur lambda limite grandement la surface d'attaque car il est peu probable qu'il ai plus de trois quatre utilisateurs actifs sur ta machine.

Sur une infrastructure partagée (université, cloud, entreprise, etc.) avec des potentiellement des centaines d'utilisateurs c'est un problème.
votre avatar
Oui c'est dommage, sinon on pourrait tenter de passer en root sur la Freebox, ce serait cool ! :langue: