Hard times

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.

• Copy fail : depuis 2017, une faille dans le noyau Linux permettait à un utilisateur de passer root

Hard times

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.

• Copy fail : depuis 2017, une faille dans le noyau Linux permettait à un utilisateur de passer root

L’assistance IA mise en place par Meta pour la gestion des comptes Instagram a autorisé pendant plusieurs semaines n’importe qui d’assez malin à changer l’adresse e-mail associée à un compte. Les propriétaires légitimes se retrouvaient donc « enfermés dehors », incapables de se connecter à leur compte et de reprendre la main.

Depuis le mois de mars, les utilisateurs de Facebook et d’Instagram qui ont besoin d’aide pour gérer leur compte peuvent faire appel à un assistant IA spécialisé, « fiable, rapide, efficace, disponible en tout temps », promettait Meta. Un soutien « axé sur l’action » pour résoudre les problèmes de compte « de A à Z ». Ce qui signifie réaliser des opérations particulièrement sensibles comme la réinitialisation du mot de passe ou le changement de l’e-mail associé au compte.

Depuis la mise en place de ce nouveau mécanisme IA, plusieurs profils Instagram de premier plan, comme un compte appartenant à Barack Obama, celui de la marque Sephora ou du chef des sous-officiers de la Space Force, ont été piratés ces dernières semaines. Les propriétaires légitimes de ces comptes ne pouvaient plus y accéder et pour cause, l’adresse e-mail associée avait changé sans leur autorisation.

Le « nouveau » propriétaire du compte était alors en mesure de publier n’importe quel contenu, contacter les abonnés, diffuser des arnaques, revendre le compte à des tiers… 404media rapporte que Meta aurait corrigé la vulnérabilité qui ouvrait la porte à ces margoulins. C’est la méthode qui est intéressante ici : il ne s’agit pas d’une faille de sécurité à proprement parler, mais d’ingénierie sociale appliquée aux agents IA.

Sur Telegram, des chercheurs en sécurité et des groupes de hackers ont partagé des vidéos et des captures d’écran explicitant le mode opératoire pour voler un compte Instagram. Le scénario est le suivant : l’attaquant connaît le nom d’utilisateur Instagram de la cible ; armé d’un VPN, qui lui permet d’apparaître dans le même pays ou la même région que la victime, il lance une procédure de récupération de compte.

Après avoir ouvert une conversation avec l’assistant IA de Meta, le pirate convainc le bot de remplacer l’adresse e-mail associée au compte par une adresse qu’il contrôle. L’IA envoie alors un code de validation à cette nouvelle adresse. Une fois l’adresse modifiée, l’attaquant peut demander une réinitialisation du mot de passe et prendre le contrôle du compte.

L’IA de Meta aurait accepté une opération extrêmement sensible sans vérifier correctement que l’utilisateur était bien le propriétaire du compte. Cette technique d’injection de prompts contourne les sécurités habituelles liées à un changement d’adresse e-mail, une opération qui ne peut normalement pas être effectuée sans une authentification forte et un délai ou une validation depuis l’ancienne adresse. L’assistance de Meta bénéficiait donc manifestement de privilèges extrêmement élevés, sans qu’aucun garde-fou ne vienne mettre le holà.

En décembre dernier, OpenAI abordait les injections de prompts sur le fond, et admettait qu’il s’agissait d’un problème à long terme. Meta n’est pas le seul acteur IA à y faire face.

• OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »

L’assistance IA mise en place par Meta pour la gestion des comptes Instagram a autorisé pendant plusieurs semaines n’importe qui d’assez malin à changer l’adresse e-mail associée à un compte. Les propriétaires légitimes se retrouvaient donc « enfermés dehors », incapables de se connecter à leur compte et de reprendre la main.

Depuis le mois de mars, les utilisateurs de Facebook et d’Instagram qui ont besoin d’aide pour gérer leur compte peuvent faire appel à un assistant IA spécialisé, « fiable, rapide, efficace, disponible en tout temps », promettait Meta. Un soutien « axé sur l’action » pour résoudre les problèmes de compte « de A à Z ». Ce qui signifie réaliser des opérations particulièrement sensibles comme la réinitialisation du mot de passe ou le changement de l’e-mail associé au compte.

Depuis la mise en place de ce nouveau mécanisme IA, plusieurs profils Instagram de premier plan, comme un compte appartenant à Barack Obama, celui de la marque Sephora ou du chef des sous-officiers de la Space Force, ont été piratés ces dernières semaines. Les propriétaires légitimes de ces comptes ne pouvaient plus y accéder et pour cause, l’adresse e-mail associée avait changé sans leur autorisation.

Le « nouveau » propriétaire du compte était alors en mesure de publier n’importe quel contenu, contacter les abonnés, diffuser des arnaques, revendre le compte à des tiers… 404media rapporte que Meta aurait corrigé la vulnérabilité qui ouvrait la porte à ces margoulins. C’est la méthode qui est intéressante ici : il ne s’agit pas d’une faille de sécurité à proprement parler, mais d’ingénierie sociale appliquée aux agents IA.

Sur Telegram, des chercheurs en sécurité et des groupes de hackers ont partagé des vidéos et des captures d’écran explicitant le mode opératoire pour voler un compte Instagram. Le scénario est le suivant : l’attaquant connaît le nom d’utilisateur Instagram de la cible ; armé d’un VPN, qui lui permet d’apparaître dans le même pays ou la même région que la victime, il lance une procédure de récupération de compte.

Après avoir ouvert une conversation avec l’assistant IA de Meta, le pirate convainc le bot de remplacer l’adresse e-mail associée au compte par une adresse qu’il contrôle. L’IA envoie alors un code de validation à cette nouvelle adresse. Une fois l’adresse modifiée, l’attaquant peut demander une réinitialisation du mot de passe et prendre le contrôle du compte.

L’IA de Meta aurait accepté une opération extrêmement sensible sans vérifier correctement que l’utilisateur était bien le propriétaire du compte. Cette technique d’injection de prompts contourne les sécurités habituelles liées à un changement d’adresse e-mail, une opération qui ne peut normalement pas être effectuée sans une authentification forte et un délai ou une validation depuis l’ancienne adresse. L’assistance de Meta bénéficiait donc manifestement de privilèges extrêmement élevés, sans qu’aucun garde-fou ne vienne mettre le holà.

En décembre dernier, OpenAI abordait les injections de prompts sur le fond, et admettait qu’il s’agissait d’un problème à long terme. Meta n’est pas le seul acteur IA à y faire face.

• OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »