Une image NTFS3 forgée donne le root à tout utilisateur local dès le montage d’une clé USB

Deux mois. Une ligne de code. euid=0. Le pilote NTFS3 du noyau Linux restaure les bits setuid depuis des données disque non fiables, ce qui signifie qu’une image NTFS forgée sur une clé USB produit un binaire setuid-root à l’instant même où le volume est monté. Signalé en privé par son découvreur il y a deux mois, le bug reste non corrigé dans le noyau mainline au 22 août 2026.

La faille a été rendue publique par Vova Tokarev sur la liste de diffusion du pilote, après deux mois sans réponse. C’est une escalade de privilèges locale — il faut un accès physique ou un montage déclenché à distance — mais son déclencheur est aussi banal qu’un automontage de bureau.

Le mécanisme : le mode vient du disque, pas de l’utilisateur

NTFS stocke des attributs étendus (EA) propres à Linux : $LXUID, $LXGID et $LXMOD. Ils servent à faire correspondre la propriété et les permissions Unix aux fichiers d’un volume NTFS. Le problème est que le pilote NTFS3 fait confiance à ces valeurs sans les filtrer.

Dans fs/ntfs3/xattr.c, à la ligne 1022, le pilote charge le mode d’inode directement depuis l’attribut lu sur le disque :

inode->i_mode = le32_to_cpu(value[2]);

Cette ligne recopie S_ISUID et S_ISGID depuis des données non fiables. Une image NTFS forgée peut donc placer $LXUID=0, $LXGID=0 et $LXMOD=0104755 directement dans la MFT. Au montage, le fichier apparaît comme appartenant à root et portant le bit setuid. Aucun appel à setxattr() n’est nécessaire — les attributs étendus sont déjà sur le disque, et le contrôle -EPERM ne s’applique pas.

Pourquoi l’automontage aggrave tout

Le dernier maillon est le plus banal. Les automonteurs de bureau, comme udisks, montent les volumes NTFS avec le bit suid activé par défaut. Brancher une clé USB forgée sur un poste de travail fait donc passer n’importe quel utilisateur local à euid=0, sans qu’aucune élévation explicite ne soit demandée.

La correction proposée par Tokarev tient en une ligne : masquer les deux bits au lieu de les recopier aveuglément.

inode->i_mode = le32_to_cpu(value[2]) & ~(S_ISUID | S_ISGID);

C’est un masquage binaire trivial — ce qui rend le statut « non corrigé » d’autant plus notable.

Un correctif d’une ligne, deux mois d’attente

Le découvreur indique avoir signalé le problème en privé environ deux mois avant la publication, sans résolution. La divulgation est donc passée par la liste de diffusion du pilote NTFS3, avec une preuve de concept complète et une démonstration fonctionnelle.

Phoronix, qui relaie l’information le 22 août 2026, précise que le pilote NTFS3 mainline n’a toujours pas reçu de correctif au moment de la publication. Le bug n’affecte pas l’autre pilote NTFS encore en maturation dans l’arbre du noyau, ni ntfs-3g, le pilote utilisateur FUSE que de nombreuses distributions utilisent par défaut.

Les contournements en attendant le correctif

En attendant que la ligne soit corrigée en mainline puis rétroportée dans les branches stables, trois mesures réduisent l’exposition :

• Désactiver l’automontage des médias amovibles sur les postes de travail, ou le restreindre à une session sans privilèges ;
• Monter explicitement avec nosuid tout volume NTFS dont on ne maîtrise pas la provenance ;
• Basculer sur ntfs-3g (FUSE) si le montage en écriture est nécessaire, ou sur le pilote ntfs historique en lecture seule.

# Vérifier quel pilote a pris en charge un volume NTFS monté
mount | grep -i ntfs

# Monter explicitement sans suid
mount -t ntfs3 -o nosuid /dev/sdX1 /mnt/ntfs

La vérification est immédiate : si la sortie de mount affiche ntfs3, le volume est géré par le pilote vulnérable.

Un pilote récent, déjà partout

NTFS3 n’est pas un pilote marginal. Développé par Paragon Software, il a été intégré au noyau mainline en 2021, avec la version 5.15, pour offrir une lecture-écriture native des volumes Windows plus rapide que ntfs-3g, l’alternative FUSE en espace utilisateur. Depuis, il est devenu le pilote par défaut de nombreuses distributions pour le montage automatique des clés USB et des disques externes formatés NTFS.

Pour mapper la propriété et les permissions Unix sur un système de fichiers qui n’a pas cette notion, NTFS3 s’appuie sur des attributs étendus propres à Linux stockés dans la MFT : $LXUID, $LXGID et $LXMOD. C’est ce mécanisme d’interopérabilité, pensé pour la compatibilité, qui est détourné : le pilote restaure ces attributs sans vérifier que les bits de privilège qu’ils contiennent sont légitimes.

Qui est concerné, qui ne l’est pas

L’exposition n’est pas uniforme. Les postes de travail avec environnement de bureau sont les plus touchés : udisks y monte automatiquement les volumes NTFS avec suid, et n’importe quel utilisateur de la machine peut brancher une clé. Les serveurs sans automontage ni accès physique sont peu exposés.

Ne sont pas affectés par ce vecteur précis : les systèmes qui montent explicitement avec nosuid, ceux qui utilisent ntfs-3g (FUSE, donc en espace utilisateur, sans accès direct aux bits setuid du noyau), et ceux qui emploient le pilote ntfs historique en lecture seule.

Le cas des environnements virtualisés mérite aussi attention : une machine virtuelle dotée d’un passthrough USB réplique le risque dans l’invité, et un conteneur privilégié qui monte un volume NTFS non fiable peut transmettre l’escalade vers l’hôte. La vérification tient en une commande : si mount affiche ntfs3 pour un volume dont vous ne maîtrisez pas la provenance, le risque est présent tant que le correctif n’est pas livré.

La leçon du setuid

Le bit setuid est l’un des mécanismes les plus anciens et les plus délicats d’Unix : il permet à un binaire de s’exécuter avec les privilèges de son propriétaire, historiquement root. Depuis des décennies, la règle d’hygiène veut qu’un administrateur ne pose ce bit que sur des binaires audités, jamais sur un fichier dont la provenance n’est pas maîtrisée. Un pilote qui restaure ce bit depuis un support amovible non fiable contourne cette règle sans que personne n’ait rien à configurer.

C’est une régression d’autant plus notable que la correction est triviale — un masque binaire — et que le problème était connu depuis deux mois au moment de la divulgation. La lenteur n’est pas technique : elle est dans la gouvernance d’un pilote dont les correctifs de sécurité doivent encore être validés puis rétroportés dans chaque branche stable.

Verdict

Si vous gérez des postes de travail Linux avec des utilisateurs non privilégiés qui branchent des clés USB, appliquez les contournements maintenant : désactivez l’automontage ou forcez nosuid sur les volumes NTFS. Le risque est réel — l’exploit est déterministe, sans condition de configuration exotique — et le correctif n’est pas encore livré.

Si vous gérez des serveurs, l’exposition est faible : un serveur n’automonte pas de médias amovibles, et personne d’autre qu’un administrateur n’y branche de clé. Concentrez la surveillance sur les postes et les postes partagés.

Le fond du problème dépasse NTFS3 : un pilote de système de fichiers qui restaure des métadonnées de privilège depuis un support non fiable recrée la faille de setuid que le monde Unix pensait avoir appris à maîtriser. Un masque binaire aurait dû fermer le dossier en juin — il attend toujours.

Références

• Specially Crafted NTFS File-System Image Allows Root Access On Linux With NTFS3 Driver — Phoronix, 22 août 2026
• Publication de Vova Tokarev sur la liste NTFS3, consulté le 23 août 2026