CVE-2024-6387
regreSSHion (Openssh Unauthenticated Remote Code Execution)

Versions concernées 

• OpenSSH < 4.1p1 sur système linux basé sur la glibc 

• OpenSSH >= 8.5p1 et < 9.8p1 sur système linux basé sur la glibc

Status des produits Gatewatcher 

Les produits gatewatcher supportés ne sont pas concernés par cette vulnérabilité.

OpenSSH, un outil d’administration à distance largement utilisé et reconnu pour sa sécurité, a été identifié avec une vulnérabilité critique. Le 1er juillet 2024, les chercheurs de la société Qualys ont annoncé la découverte d’une vulnérabilité d’exécution de code arbitraire à distance non-authentifiée dans une version à jour d’OpenSSH, même dans sa configuration par défaut. 

Nommée “regreSSHion” en référence au fait que cette vulnérabilité est apparue suite à la suppression d’une correction effectuée précédemment, la CVE-2024-6387 est considérée comme d’importance Haute d’après sa note CVSSv3.1 (8.1). 

Cette vulnérabilité se base sur une race condition dans le gestionnaire du signal SIGALRM. Ce gestionnaire appelle différentes fonctions qui ne sont pas conçues pour être appelées de manière asynchrone.  

Bien que le fonctionnement global de la vulnérabilité soit identique dans tous les cas, l’analyse détaillée de la vulnérabilité publiée par les chercheurs, indique que différents chemins peuvent être empruntés afin de déclencher la vulnérabilité. Ces chemins dépendent du système d’exploitation sous-jacent, mais plusieurs chemins peuvent également coexister au sein d’un même système.  

Sur les systèmes d’exploitation récents, la technique consiste à s’assurer de l’organisation de la mémoire via un jeux d’allocation/libération de mémoire qui, une fois effectuée, permettra l’appel au code malicieux. 

Cependant, comme l’indique la publication, des recherches sont toujours en cours, l’exploitation ayant été réussie sur des systèmes 32 bits, mais l’exploitation sur des systèmes 64 bits pouvant être plus longue.   

En raison de la nature aléatoire des race conditions et de la présence de mécanismes de protection de la mémoire comme l’ASLR, cette attaque nécessite de nombreuses tentatives afin d’aboutir.  

Selon le document détaillant la vulnérabilité, pour un système récent, avec la configuration par défaut (MaxStartups 100, LoginGraceTime 120s), la durée estimée pour obtenir un accès root est d’environ 6 à 8 heures. 

Une méthode de détection relativement générale serait une règle de ce type :  

alert ssh any any -> any any (msg: »EVENT Possible CVE-2024-6387 exploitation attempt »; flow: established,to_server; threshold: type both, track by_both, count 100, seconds 120; reference:cve,2024-6387; metadata: created_at 2024_07_01, cve CVE_2024_6387; sid:10000001; rev:1;) 

Les preuves de concept disponibles étant assez sommaire, les règles de détections seront probablement amenées à évoluer très rapidement. 

Mise à jour 02/07/2024 : Une règle a été mise à disposition dans le ruleset par défaut permettant d’alerter lorsqu’un serveur SSH répond avec une bannière contenant une version vulnérable.

Cependant, comme d’ordinaire, il est fortement conseillé de valider l’application de nouvelles règles dans un environnement de préproduction. Et il est également important de rappeler que cette potentielle détection ne remplace pas la mise en place des correctifs.  

Comme souligné précédemment, les variantes peuvent être nombreuses pour obtenir un résultat similaire. 

Les chercheurs ayant remonté la problématique ont travaillé en collaboration avec les équipes d’openSSH ce qui a permis une mise à jour rapide. La version 9.8p1 est disponible depuis le 01 juillet 2024.  

Au vu du nombre de systèmes pouvant être touchés et des variations, il est nécessaire de vérifier si le correctif a été mis à disposition par la distribution concernée. 

Bien que le risque principal soit une compromission initiale, il est important de garder à l’esprit que ce type de vulnérabilité peut également permettre à un attaquant ayant déjà un accès initial de se déplacer latéralement. Il est donc crucial de corriger rapidement tous les systèmes concernés, y compris ceux n’étant pas directement exposés sur internet. 

Un contournement est possible pour se prémunir contre l’exploitation de cette vulnérabilité : fixer le paramètre `LoginGraceTime` à 0. Attention cependant, ce contournement expose le serveur SSH à un déni de service par utilisation de toutes les ressources allouées à la gestion des nouvelles connexions (MaxStartups). 

Enfin, cette vulnérabilité prouve s’il en est besoin qu’aucun logiciel n’est à l’abris d’une vulnérabilité, soulignant l’importance d’une segmentation forte et d’un système de détection.