Un jeton pour les refuser tous

Quatre entreprises de la tech souhaitent ajouter une ligne dans le fichier robots.txt pour que les données des sites concernés ne soient pas utilisées dans l’entrainement des IA. S’agissant d’une démarche déclarative, ses limites sont claires.

Le 30 octobre, Google, Microsoft, Anthropic et OpenAI ont annoncé qu’ils respecteraient une même ligne dans le fichier robots.txt pour refuser ou accepter l’utilisation d’un site à des fins d’entraînement de l’IA générative.

Le texte qui la définit est intitulé « Machine-Readable Training Preference Signal » et a été écrit par Kevin Kelley, ingénieur chez Anthropic. Il vise la normalisation par l’IETF, l’organisme qui fixe les standards techniques d’Internet, et doit expirer le 3 mai 2027 si aucune nouvelle version n’est publiée d’ici là.

Une simple ligne ?

La proposition cherche à simplifier une situation. Actuellement, un éditeur souhaitant en effet refuser l’entrainement sur ses données doit viser chaque robot séparément. Par exemple, GPTBot chez OpenAI ou Google-Extended chez Google. Le texte ajoute un nouveau jeton, « __usage_ai-training », qui doit permettre d’exprimer une seule préférence auprès de tous les fournisseurs qui s’y engagent.

Ce jeton se place dans la ligne User-Agent, comme on le fait déjà avec les noms des robots. Un Disallow exprime un refus de l’entraînement, un Allow un accord, chemin par chemin. Le texte illustre le fonctionnement par le code suivant, qui refuse l’entraînement sur tout le site, sauf pour un espace presse :

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

La date de support diffère d’un éditeur à un autre, mais tous s’engagent à respecter le nouveau signal dans les prochains mois.

Des limites évidentes

Il y a évidemment des limites. D’une part, le jeton ne bloque pas l’exploration. Le brouillon le décrit comme indépendant des règles visant les robots, qui continuent donc de s’appliquer comme avant. D’autre part, il est déclaratif et ne lie que les fournisseurs qui s’y engagent. De plus, il ne concerne que les contenus récupérés après son ajout, et ne retire ainsi rien des modèles déjà entraînés.

Surtout, l’engagement repose sur la seule parole des fournisseurs. OpenAI le présente comme une démarche volontaire (OpenAI), et le brouillon ne prévoit aucun contrôle ni sanction. Un éditeur n’a aucun moyen de vérifier qu’un contenu refusé n’a pas servi à entraîner un modèle. Le robots.txt lui-même, à l’origine, n’a d’ailleurs aucune valeur contraignante.

Enfin, le jeton ne lie pas non plus les entreprises qui ne s’y sont pas engagées. Apple, Amazon ou encore Meta ne s’y sont pas engagées. Rien n’oblige par ailleurs les autres développeurs de modèles à lire ce jeton, pas plus que les robots qui ignorent déjà le robots.txt.

Un contournement plus qu’un correctif

Une énorme faille de sécurité a été découverte et corrigée dans OpenSSH, qui permet d’administrer à distance la plupart des serveurs Linux. Exploitée, elle pouvait laisser entrer des pirates sur des serveurs Alpine Linux sans besoin de connaitre le mot de passe : il suffisait d’en écrire un aléatoire d’au moins 256 caractères.

Le projet OpenSSH a publié en urgence un correctif pour la faille dès le 5 novembre. Selon le message de Damien Miller, l’un des principaux développeurs, le correctif a été proposé moins de 24 heures après la réception du signalement.

L’équipe d’OpenSSH demande aux administrateurs concernés de couper aussi rapidement que possible la connexion par mot de passe, voire le service SSH lui-même, tant que le correctif n’est pas installé. Damien Miller indique que la grande majorité des systèmes d’exploitation ne sont pas concernés : Windows, macOS, la plupart des distributions Linux (comme Debian, Ubuntu, Red Hat, Fedora…) ou encore les systèmes BSD ne présentent pas de risque d’exploitation dans leur configuration par défaut.

Pourquoi une telle urgence dans ce cas ? Parce que pour être exploitée, la faille nécessite une configuration précise, qui est justement celle par défaut dans Alpine Linux. Or, cette distribution est souvent utilisée pour sa légèreté dans certains environnements, notamment cloud.

Sur Alpine Linux, un correctif à installer au plus vite

Dans l’avis publié par l’équipe d’Alpine Linux hier soir, on peut lire qu’un serveur sous Alpine Linux est vulnérable s’il réunit trois conditions : le service SSH accepte les connexions par mot de passe (c’est le cas par défaut), il existe au moins un compte sans mot de passe, et au moins un autre compte en possède un.

Si vous estimez que personne n’utilise des comptes sans mot de passe, détrompez-vous. Il s’agit le plus souvent de comptes auxquels les propriétaires se connectent avec une clé cryptographique, la méthode étant d’ailleurs plus sûre. La vulnérabilité, référencée CVE-2026-123158, peut donc être exploitée pour ouvrir l’accès à ces comptes sans mot de passe, clé cryptographique ou pas. Tout ce dont le pirate a besoin selon Alpine, c’est de joindre le serveur par le réseau et de connaitre le nom d’un de ces comptes.

Sur cette distribution, le compte administrateur (root) est livré sans mot de passe, le rendant en théorie vulnérable. Par défaut, OpenSSH refuse toute connexion par mot de passe au compte administrateur, quel que soit le mot de passe tapé. C’est en théorie suffisant. Cette protection tombe toutefois si un autre compte a les droits nécessaires pour devenir administrateur. C’est le cas dans les versions 3.18.11 à 3.24.3 des images d’Alpine Linux destinées au cloud. Dès lors, ces machines deviennent vulnérables dès qu’un mot de passe est défini sur un autre compte, ouvrant la voie au pirate pour un accès complet au serveur.

Comme l’indique The Hacker News, il est recommandé de vérifier si d’autres systèmes sont concernés, car le composant impliqué (musl) est aussi utilisé dans des distributions spécialisées dans l’embarqué comme OpenWrt, Buildroot et Yocto. En revanche, les conteneurs Docker qui ne font pas tourner de serveur SSH, les serveurs où la connexion par mot de passe est désactivée, et les machines installées via cloud-init (qui désactive cette connexion) ne sont pas affectés.

Comment un mot trop long peut-il ouvrir la porte ?

Un système ne stocke pas les mots de passe en clair. Il ne conserve que leur empreinte, calculée via une transformation mathématique irréversible. Pour vérifier un mot de passe, le serveur calcule l’empreinte de ce qui a été tapé et la compare simplement à celle enregistrée sur la machine.

La vulnérabilité réside dans la rencontre entre deux conventions, qui n’ont rien d’anormal quand elles sont prises isolément. Ainsi, pour un compte sans mot de passe, Linux enregistre un unique astérisque à la place de l’empreinte. Mais Alpine utilise la bibliothèque musl, pour des besoins de légèreté. Celle-ci, quand elle doit calculer l’empreinte d’un mot de passe de plus de 256 caractères, refuse. Pour signaler l’erreur, elle renvoie… un simple astérisque. Le problème est alors évident : le serveur compare les deux, en déduit qu’il s’agit de la même empreinte et ouvre la session. Pour effectuer ce calcul, le serveur emprunte un paramètre depuis un compte possédant un vrai mot de passe, d’où la nécessité d’avoir au moins un tel compte configuré.

Les distributions n’utilisant pas musl ne sont pas touchées car leur bibliothèque système signale l’erreur autrement. Celles qui délèguent la vérification à un module d’authentification séparé (PAM) ne sont pas non plus concernées.

Ce comportement dans musl remonte à 2012, tandis que la manière dont OpenSSH traite les comptes sans mot de passe vient d’un changement introduit en 2016. La faille existe donc depuis une décennie environ.

Le correctif d’OpenSSH refuse désormais toute comparaison avec une empreinte enregistrée trop courte pour être valide. OpenSSH le présente d’ailleurs davantage comme un contournement, la cause profonde restant dans musl. À noter que le problème avait été remonté en 2024, l’attitude de musl étant alors jugée incorrecte sur l’utilisation de l’astérisque.

Les actions à réaliser

Sans surprise, la meilleure parade est la mise à jour, mais il faudra redémarrer le service SSH ensuite, car l’installation seule du correctif n’est pas suffisante si le serveur est actif.

Alpine a publié des paquets corrigés pour toutes ses versions depuis la 3.16, y compris celles qui ne sont plus officiellement suivies, comme la 3.21 (son support est terminé depuis le 1ᵉʳ novembre), signe de l’importance de la situation. Les nouvelles versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent directement la correction.

Comme indiqué précédemment, sur les machines où la mise à jour est impossible pour le moment, il suffit de désactiver la connexion par mot de passe. Alpine recommande d’ailleurs de bien vérifier que la connexion par clé cryptographique fonctionne avant de procéder, pour ne pas se retrouver bloqué hors du serveur. Dans les installations cloud, il faudra s’assurer que toutes les machines virtuelles lancées sont corrigées, car la simple reconstruction des images ne protège pas les instances déjà actives.

On notera enfin que tout le monde ne semble pas d’accord sur le niveau de dangerosité de cette faille. Sur le site du NIST, le score CVSS est en effet de 8,1, ce qui la classe comme « élevée », pas « critique ». Dans son message, Damien Miller (de l’équipe OpenSSH) évoque pourtant bien une faille critique.

Nouvelle version pour le navigateur alternatif basé sur Chromium et orienté vers les « power users ». L’ajout majeur de cette mouture est l’arrivée d’un nouveau sélecteur pour le niveau de blocage que l’on souhaite contre les publicités et traqueurs.

Jusqu’à présent, les utilisateurs avaient le choix entre trois options : pas de blocage, bloquer les traqueurs, bloquer les traqueurs et les publicités. Désormais, les traqueurs et publicités sont regroupés et le sélecteur propose quatre réglages :

• Désactivé
• Léger, qui bloque la plupart des traqueurs et certaines publicités
• Fort, qui augmente le niveau de blocage, au risque de perturber certains sites
• Agressif, le niveau maximal de blocage, au risque de « casser » certains sites

Le navigateur laisse cependant la possibilité de définir des niveaux personnalisés en fonction des sites. L’éditeur norvégien pousse d’ailleurs dans ce sens : « Mettez ce DJ-set sur Youtube à fond sans que les publicités ne brisent votre rythme avec le niveau « Agressif  ». Gardez le niveau « Léger » sur votre appli de banque pour que chaque formulaire fonctionne comme prévu. Refusez la protection sur le petit site indépendant en qui vous avez confiance et sur lequel vous tolérez de voir des publicités ». On peut également créer un niveau général de blocage personnalisé, où l’on pourra notamment choisir les listes de blocage.

Vivaldi 8.3 ajoute aussi deux options pour les onglets verticaux. La première permet de déployer la barre d’onglets au survol de la souris, offrant une solution à mi-chemin entre la vue minimaliste (qui n’affiche que les favicons) et la vue classique (qui affiche les noms des pages ouvertes). La seconde regroupe les onglets épinglés pour les afficher en grille, si la colonne est élargie. Dans le cas d’une colonne minimaliste, les favicons s’empilent comme d’habitude. Il s’agit du nouveau comportement par défaut, mais une option permet de le désactiver pour revenir à l’ancien (un site épinglé par liste).

Parmi les autres améliorations, on trouve en outre une fonction bienvenue : on peut copier une liste de liens et la coller dans la barre d’adresses, Vivaldi ouvrant alors chaque lien dans un onglet dédié. Selon l’éditeur, c’est une solution pratique quand vous recevez par exemple une liste de liens dans un e-mail. La version 8.3 ajoute également une fonction « Copier l’URL sans traqueurs » dans le menu contextuel depuis la barre d’adresses, un mode lecture plus réactif (lancement plus rapide et défilement plus fluide), ainsi que le support de l’API Tab Groups de Chrome pour les extensions