Avec un mot de passe de plus de 256 caractères, tapé au hasard, un pirate pouvait ouvrir une session SSH sur certains serveurs Alpine Linux dès sa première tentative, sur un compte dépourvu de mot de passe. Les développeurs d’OpenSSH et d’Alpine ont publié un correctif en urgence.
Alpine Linux est une distribution très légère, appréciée pour faire tourner des conteneurs Docker et de petits serveurs. Sur certaines machines équipées de cette distribution, il suffisait à un attaquant de joindre le port SSH pour se connecter sans connaître le moindre mot de passe. Le chercheur Özgün Kültekin a signalé la faille au projet OpenSSH, dont l’équipe l’a classée critique. Personne n’a signalé d’attaque à ce jour. Mais d’après l’avis de sécurité d’Alpine, l’intrus réussit sa connexion à chaque essai, avec une seule tentative.
Un mot de passe de plus de 256 caractères pour ouvrir les comptes sans mot de passe
La faille remonte à 2016. Pour corriger une autre vulnérabilité, CVE-2016-6210, les développeurs d’OpenSSH ont alors modifié la vérification des mots de passe sur les serveurs configurés sans PAM, les modules chargés d’ordinaire de l’authentification sous Linux. Sans eux, le mot de passe tapé est haché avec la fonction crypt(), puis comparé à l’empreinte enregistrée sur la machine. Ce calcul a besoin d’un sel, une donnée aléatoire mélangée au mot de passe. Mais un compte sans mot de passe, réservé par exemple à la connexion par clé, ne contient qu’un astérisque. Pour ces comptes, le sel est donc emprunté à un autre compte de la machine, protégé par un vrai mot de passe haché en SHA-256 ou SHA-512.
Le second problème date de 2012. Alpine est construite avec musl, une bibliothèque C plus légère que la glibc de Debian ou d’Ubuntu. Avec musl, un astérisque est renvoyé en guise d’erreur par crypt() dès que le mot de passe dépasse 256 octets. Cet astérisque est identique à celui du compte sans mot de passe, et la connexion est acceptée.
Sur Alpine, ces comptes vides sont nombreux. Le compte root est livré avec un astérisque depuis la version 3.16 environ. Root est protégé par défaut par le réglage PermitRootLogin prohibit-password, mais un pirate peut entrer par un autre compte, puis devenir administrateur avec doas, l’équivalent de sudo. Si vous avez déployé Alpine dans le cloud avec une image officielle tiny-cloud, de la 3.18.11 à la 3.24.3, vous disposez d’un compte alpine sans mot de passe, autorisé à passer root sans rien taper. Ces images sont sûres au premier démarrage, mais vulnérables dès que vous définissez un mot de passe sur la machine, pour la console par exemple.
Dans la version 10.6p2, les développeurs d’OpenSSH ont bloqué toute correspondance avec un champ de moins de quatre caractères. Pour eux, la cause réelle se trouve en dehors du serveur SSH, et ce correctif n’est qu’un contournement. Selon Damien Miller, l’équipe considère les longues périodes de secret avant un correctif dangereuses, car des agents d’IA ont récemment retrouvé, parfois en quelques heures, des bugs qui venaient d’être signalés.
Une mise à jour à compléter par un redémarrage de sshd
Si vous n’exécutez pas sshd dans votre conteneur Docker, vous ne risquez rien. Les distributions construites avec la glibc, Debian ou Ubuntu, ne sont pas concernées non plus, pas plus que les serveurs où la connexion par mot de passe est désactivée.
Alpine a publié des paquets corrigés pour toutes ses versions depuis la 3.16, jusqu’à celles qu’elle ne maintient plus. Si vous utilisez Alpine sur un serveur, lancez apk upgrade -U -a, puis rc-service sshd restart. Sans cette seconde commande, vous laissez tourner l’ancien sshd, toujours vulnérable. Le correctif est inclus dans les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4, et dans les images tiny-cloud construites à partir d’elles.
Si vous ne pouvez pas installer la mise à jour tout de suite, « réglez PasswordAuthentication sur no ou désactivez SSH sur ces systèmes, IMMÉDIATEMENT », souligne Damien Miller, développeur d’OpenSSH. Avant de couper les mots de passe, vérifiez que votre connexion par clé fonctionne, et gardez votre session ouverte. Dans son avis, Alpine propose un script pour ajouter ce réglage, tester la configuration avec sshd -t et redémarrer le service.
Ensuite, cherchez dans le fichier /var/log/messages des lignes Accepted password for sur vos comptes sans mot de passe, root, alpine ou ceux réservés aux clés. Vérifiez aussi les comptes créés récemment et les clés SSH autorisées sur la machine. Si vous ne pouvez pas exclure une connexion de ce type, Alpine recommande de considérer le serveur compromis.
Özgün Kültekin conseille enfin de contrôler les autres systèmes construits avec musl. Votre routeur sous OpenWrt est concerné seulement si vous avez remplacé Dropbear, le serveur SSH livré par défaut, par OpenSSH. Pensez aussi aux systèmes embarqués fabriqués avec Buildroot ou Yocto. Pour l’instant, la faille n’a toujours pas de numéro CVE.
