Des chercheurs ont découvert une importante faille de sécurité dans OpenSSH. Il s’agit en fait d’une régression : la faille a été réintroduite en 2020, alors qu’elle avait été corrigée en 2006. Au vu du danger entrainé par la faille, critique, il est recommandé de mettre à jour rapidement.

Chez Qualys, une équipe de chercheurs a averti d’une faille critique dans OpenSSH. Estampillée CVE-2024-6387 et nommée RegreSSHion, elle peut permettre l’exécution d’un code à distance, sans authentification, sur tous les systèmes Linux basés sur la bibliothèque glibc (implémentation open source de la bibliothèque standard C). Le tout avec les droits administrateurs. Plusieurs distributions ont déjà émis des bulletins de sécurité sur le problème, notamment Debian, ArchLinux, Oracle Linux, Red Hat et Ubuntu.

« Cette vulnérabilité, si elle est exploitée, peut conduire à une compromission totale du système où un attaquant peut exécuter un code arbitraire avec les privilèges les plus élevés, ce qui entraîne une prise de contrôle complète du système, l'installation de logiciels malveillants, la manipulation de données et la création de portes dérobées pour un accès persistant », décrit ainsi Bharat Jogi, directeur de la recherche sur les menaces chez Qualys.

L’exploitation pourrait « faciliter la propagation dans le réseau, permettant aux attaquants d'utiliser un système compromis comme point d'ancrage pour traverser et exploiter d'autres systèmes vulnérables au sein de l'organisation ».

Une ancienne faille de retour

Le risque est d’autant plus important qu’OpenSSH est extrêmement utilisé. Cette suite d’utilitaires réseau permet d’établir des connexions sécurisées sur un réseau informatique, via SSH. Elle joue un rôle crucial dans un très grand nombre de systèmes connectés à internet. En outre, RegreSSHion n’est pas réellement une nouvelle faille. Elle a été réintroduite par erreur en octobre 2020 dans la version OpenSSH 8.5p1.

La vulnérabilité, de type Race Condition (situation de compétition) réside dans le gestionnaire de signaux. Il s’agit d’un composant de la bibliothèque glibc chargé de surveiller la venue d’évènements graves, comme une tentative de division par zéro. Si un client établit une connexion, mais ne parvient pas à s’authentifier dans le délai imparti (120 secondes par défaut, paramètre LoginGraceTime), un appel asynchrone est lancé au gestionnaire, via un signal SIGALRM.

Ce dernier est ensuite repris par plusieurs processus. Cependant, ces derniers ne vérifient pas la cohérence de l’état de la mémoire entre les moments où le signal a été émis et reçu. Ces processus ne sont pas « async-signal-safe ». Dans le cas présent, le signal SIGALRM est récupéré par le processus syslog, qui va ensuite allouer et libérer de la mémoire (respectivement avec les fonctions malloc et free).

Un pirate peut employer ce fonctionnement pour envoyer des données à un serveur ciblé, dont une clé publique SSH spécialement conçue. À la lecture de la clé, le serveur alloue de la mémoire aux données. Si un signal SIGALRM est émis pendant cette opération, des appels malloc et free peuvent être déclenchés pour créer un état incohérent de la mémoire, pouvant alors mener à une exécution de code.

Une faille sérieuse, mais difficile à exploiter

La prise de contrôle à distance sans authentification est le pire des scénarios pour une faille de sécurité. C’est le cas ici, avec un score CVSSv3.1 de 8.1 sur 10.

Pour autant, la brèche est complexe à exploiter. Comme l’indiquent les chercheurs, elle requiert une approche statistique, car les pirates doivent envoyer de nombreuses requêtes d’authentification SSH. Ils doivent réussir à déclencher l’émission d’un signal SIGALRM au moment où OpenSSH charge la clé publique spécialement conçue.

Les chercheurs expliquent qu’il peut ainsi falloir jusqu’à 10 000 tentatives pour obtenir l’effet escompté, ce qui peut prendre jusqu’à 8 heures. L’équipe de Qualys ajoute avoir créé un exploit fonctionnel, qui ne sera révélé que quand une majorité des systèmes auront été mis à jour. Il a été testé avec succès sur des serveurs Linux 32 bits avec ASLR activée. L'address space layout randomization (distribution aléatoire de l'espace d'adressage) est un important mécanisme de défense qui permet de stocker des informations sensibles dans des zones aléatoires de la mémoire.

Ce sont les deux principaux facteurs de limitation à l’exploitation : le temps nécessaire et les systèmes 32 bits. Les systèmes 64 bits, malgré des tests, ont résisté aux attaques. Selon les chercheurs toutefois, en dépit d’un nombre d’adresses mémoire exponentiellement plus élevé, rien n’empêche en théorie RegreSSHion de fonctionner sur ces machines, même avec l’ASLR activé. Même constat pour des systèmes 32 bits sans glibc : c’est possible, mais l’attaque n’a pas encore été démontrée.

Les systèmes vulnérables et les actions à prendre

Toutes les versions de 8.5p1 à 9.7p1 d’OpenSSH sont vulnérables sur les systèmes Linux 32 bits avec glibc et l’ASLR activée. Les versions antérieures à la 4.4p1 sont également concernées.

Selon les chercheurs, cela laisse quand même plusieurs millions de serveurs potentiellement vulnérables. Le premier conseil est donc de mettre à jour la version d’OpenSSH aussi rapidement que possible. Qualys dit avoir travaillé avec les développeurs dès la découverte pour corriger rapidement le tir.

Dans tous les cas, les administrateurs devraient vérifier les journaux SSHD à la recherche de nombreuses lignes « Timeout before authentication », potentiel signe de tentatives d’exploitation. Si la distribution Linux utilisée ne dispose pas de correctif, Qualys recommande de changer la valeur de LoginGraceTime pour 0 dans le fichier de configuration. L’exécution de code arbitraire à distance ne sera plus possible, mais le serveur sera vulnérable aux attaques par déni de service.