Tailscale corrige des failles SSH permettant un accès root via le transfert de socket

Tailscale a publié la version 1.104.4 pour remédier à de graves failles de sécurité dans son serveur SSH intégré, qui pourraient permettre aux attaquants d'élever leurs privilèges jusqu'au niveau root sur les machines cibles. Ces vulnérabilités, révélées dans un rapport d'Erica Windisch de Cyberdione Labs, affectent la manière dont le service gère le transfert des connexions réseau et ont été corrigées quelques jours seulement après leur divulgation publique.

Ce qui s'est passé

Le problème central réside dans la gestion du transfert de sockets Unix par le serveur SSH de Tailscale. Lorsqu'un utilisateur établit une session SSH, le processus en arrière-plan de Tailscale effectue l'opération de transfert avec des privilèges root. Bien que le système vérifie le chemin du socket auquel il accède, une vulnérabilité liée au timing a permis aux attaquants de modifier ce chemin après la vérification mais avant l'établissement de la connexion. Cette condition de concurrence (race condition) contournait efficacement les mesures de protection destinées à restreindre l'accès aux sockets système sensibles.

Lors de tests en laboratoire, Windisch a démontré qu'un attaquant contrôlant déjà un périphérique autorisé par la politique réseau pouvait transférer des connexions vers le socket de contrôle Docker ou l'API locale tailscaled. Cet accès accordait un shell root et la capacité de lire des fichiers sensibles comme /etc/shadow sans avoir besoin d'identifiants administrateur. L'attaque ne nécessite ni vol de mots de passe ni de clés, mais uniquement un point d'appui sur un périphérique de confiance au sein du réseau Tailscale.

Tailscale a précisé que ces failles ne permettent pas aux attaquants non authentifiés de se connecter à des serveurs arbitraires. L'accès reste régi par le fichier de politique du réseau, ce qui signifie qu'un attaquant ne peut atteindre que les machines auxquelles il est déjà autorisé à accéder. Cependant, une fois à l'intérieur d'une session autorisée, l'élévation de privilèges permet un mouvement latéral vers des services réservés au root. La société a qualifié ces problèmes de graves failles de sécurité, mais a rejeté la caractérisation de l'exploit comme étant un ver auto-réplicant, notant qu'il repose sur des permissions de politique existantes plutôt que sur une propagation autonome.

Comment cela fonctionne

La vulnérabilité exploite la différence entre la vérification des permissions et le contexte d'exécution. Précédemment, le processus Tailscale vérifiait le chemin du socket puis effectuait l'opération de transfert en tant que root. En échangeant le chemin du socket durant cette fenêtre, un attaquant pouvait tromper le système pour qu'il se connecte à un socket privilégié au lieu de celui prévu. Le correctif de la version 1.104.4 modifie ce comportement afin que le transfert soit effectué par l'utilisateur connecté plutôt que par root. Il déplace également la dépendance des vérifications internes de chemin vers les permissions natives de fichiers du système d'exploitation, qui sont plus robustes contre de telles conditions de concurrence.

Ce changement adresse spécifiquement le bulletin TS-2026-014, qui couvre les failles de transfert de socket. La mise à jour résout également trois autres problèmes : un bug d'épuisement mémoire pouvant faire planter le processus Tailscale (TS-2026-015), une faille dans la fonctionnalité tailscale serve permettant le contrôle de nœuds distants via des sockets Unix (TS-2026-016), et un problème de fuite d'en-têtes dans les configurations TLS serve (TS-2026-017). Le serveur SSH de Tailscale fonctionne sous Linux et sur la build open-source de macOS, bien que le périphérique attaquant puisse être de toute plateforme.

Détails clés

• Versions affectées : La plus ancienne version affectée n'est pas spécifiée, mais la version 1.104.4 contient les correctifs.
• Prérequis : Les attaquants doivent déjà contrôler un périphérique de confiance selon la politique réseau, avec le transfert SSH activé.
• Impact : Une exploitation réussie donne accès aux sockets réservés au root, tels que le socket Docker ou l'API locale tailscaled.
• Utilisateurs de Headscale : Le serveur de contrôle headscale auto-hébergé (version 0.29.5) ne corrige pas encore ces problèmes, et le transfert SSH ne peut pas être désactivé dans sa politique.
• Divulgation : Le rapport a été publié sans coordination préalable ; Tailscale l'a reçu deux heures avant la publication publique.
• Pas de CVE : Au moment de la publication, les quatre bulletins de sécurité n'ont pas d'identifiants CVE attribués ni de scores de sévérité.

Pourquoi c'est important

Pour les équipes d'ingénierie utilisant Tailscale pour l'accès à l'infrastructure, cet incident met en lumière les risques liés à la confiance implicite dans les modèles d'identité des périphériques. Comme Tailscale SSH utilise l'identité du périphérique plutôt que des mots de passe, la compromission d'un seul périphérique de confiance peut offrir une voie d'accès vers des systèmes critiques si le transfert est activé. La rapidité avec laquelle l'exploit peut se déplacer latéralement — moins d'une seconde par étape lors des tests — signifie que les temps de détection et de réponse doivent être extrêmement rapides pour prévenir une compromission généralisée.

La situation est particulièrement difficile pour les utilisateurs de headscale, l'alternative open-source au plan de contrôle de Tailscale. Puisque headscale ne permet actuellement pas de désactiver le transfert SSH dans la politique et n'a pas encore publié de correctif, les administrateurs utilisant cette configuration doivent considérer chaque octroi SSH comme potentiellement accordant un accès root. Cela souligne l'importance de comprendre les différences entre les services managés et les alternatives auto-hébergées lors de l'évaluation des postures de sécurité.

Ce que vous pouvez faire

• Mettez à jour tous les clients et serveurs Tailscale vers la version 1.104.4 ou ultérieure immédiatement.
• Si la mise à jour n'est pas possible, définissez TS_SSH_DISABLE_FORWARDING=1 dans l'environnement du service tailscaled pour bloquer le transfert.
• Examinez les règles d'accès SSH pour vous assurer que seuls les périphériques et utilisateurs nécessaires ont la permission de se connecter.
• Activez le mode de vérification SSH pour les systèmes sensibles afin d'exiger une nouvelle authentification avant le début des sessions.
• Pour les utilisateurs de headscale, restreignez agressivement les octrois SSH et surveillez toute activité non autorisée au niveau root.
• Réinitialisez et supprimez les périphériques compromis du plan de contrôle si vous suspectez une violation, car la simple réinitialisation ne révoque pas les clés du périphérique.