CVE-2024-6387 : regreSSHion — RCE OpenSSH après 18 ans

Une condition de course dans le gestionnaire de signaux d'OpenSSH permet à des attaquants non authentifiés d'exécuter du code arbitraire en tant que root sur des serveurs Linux utilisant glibc. Surnommée « regreSSHion » — une régression de CVE-2006-5051 réintroduite accidentellement en 2020. Affecte environ 14 millions de serveurs SSH exposés à Internet. CVSS 8.1 ÉLEVÉ.

Qu'est-ce que CVE-2024-6387 ?

CVE-2024-6387 est une condition de course dans le gestionnaire de signaux du serveur OpenSSH (sshd). Lorsqu'un client ne s'authentifie pas dans le délai LoginGraceTime (120 secondes par défaut), sshd appelle SIGALRM pour terminer la connexion. Le gestionnaire de signaux appelle des fonctions non sûres pour un signal asynchrone — en particulier syslog() — ce qui peut corrompre l'état du tas lorsqu'elle est appelée en même temps que d'autres opérations.

Les chercheurs de Qualys qui ont découvert la vulnérabilité l'ont nommée « regreSSHion » car un bug identique (CVE-2006-5051) avait été corrigé en 2006, mais le correctif a été retiré par inadvertance lors de la sortie d'OpenSSH 8.5p1 en octobre 2020 — ce qui signifie que la vulnérabilité a silencieusement réexisté pendant près de quatre ans avant sa découverte.

Versions concernées

Exigence glibc : Le PoC de Qualys exploitait l'implémentation malloc de glibc. Le sshd d'OpenBSD n'est pas vulnérable. Alpine Linux (qui utilise musl libc) et macOS ne sont pas vulnérables à la technique d'exploitation démontrée, bien que la condition de course existe toujours.

La condition de course expliquée

Les gestionnaires de signaux dans les programmes C ne doivent appeler que des fonctions « sûres pour un signal asynchrone » — un petit sous-ensemble de fonctions libc pouvant être appelées en toute sécurité depuis un gestionnaire de signaux car elles n'utilisent pas d'état partagé. La fonction syslog() n'est pas sûre pour un signal asynchrone car elle utilise malloc en interne.

# Le chemin de code problématique (simplifié) :
# Quand LoginGraceTime expire :
SIGALRM → grace_alarm_handler() → syslog() → malloc() en interne
                                              ↕ COURSE
           le thread principal sshd appelle aussi        malloc() / free()

# Si les deux opérations malloc s'entrelacent :
# → Corruption du tas
# → Avec suffisamment de tentatives : disposition contrôlée du tas
# → Exécution de code à distance en tant que root

L'exploitation nécessite de gagner la condition de course de façon fiable, ce qui exige des milliers de tentatives de connexion en quelques minutes. Cela rend l'exploitation automatisée à l'échelle d'Internet un peu plus lente que les vulnérabilités classiques « fire and forget » — mais des acteurs sophistiqués disposant d'un accès persistant à une cible ont largement le temps.

Difficulté d'exploitation

Qualys a démontré une exploitation fiable sur des systèmes 32 bits (x86). Sur les systèmes 64 bits, l'ASLR augmente considérablement la difficulté. Les chercheurs notent qu'avec environ 10 000 tentatives sur 6 à 8 heures, l'exploitation est théoriquement réalisable sur des systèmes 64 bits, mais ils n'ont pas publié de PoC fonctionnel pour x86_64.

Cependant, la barrière peut être abaissée par :

• Des fuites d'informations qui neutralisent l'ASLR (exploits combinés)
• La force brute dans des environnements où fail2ban ou la limitation de débit ne sont pas configurés
• De futures recherches améliorant la technique d'exploitation
• L'accès à des systèmes 32 bits vulnérables (encore courants dans l'IoT et le Linux embarqué)

Détection

# Vérifier la version d'OpenSSH
ssh -V
sshd -V

# Vérifier la version du paquet installé (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Vérifier la version du paquet installé (RHEL/CentOS)
rpm -qa | grep openssh-server

# Rechercher des tentatives de force brute révélatrices d'une exploitation de regreSSHion
# (taux de connexion très élevé depuis une seule IP, toutes en échec pendant la période de grâce)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Rechercher des échecs de connexion à taux élevé
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Atténuation

1. Mettre à jour OpenSSH vers 9.8p1+ : Toutes les principales distributions ont publié des correctifs quelques jours après la divulgation. apt update && apt upgrade openssh-server ou équivalent.
2. Définir LoginGraceTime à 0 : Configurer LoginGraceTime 0 dans /etc/ssh/sshd_config empêche l'appel du gestionnaire SIGALRM, éliminant la condition de course (bien que cela supprime le délai de grâce) :

   echo "LoginGraceTime 0" >>  /etc/ssh/sshd_config
   systemctl reload sshd

3. Limiter le débit des connexions SSH : Configurer fail2ban ou une limitation de débit iptables pour empêcher les milliers de connexions nécessaires à l'exploitation
4. Restreindre l'accès SSH par IP : Limiter sshd à des plages d'IP de gestion connues via AllowUsers, ListenAddress, ou des règles de pare-feu
5. N'utiliser que des clés SSH : Désactiver l'authentification par mot de passe — l'authentification par clé ajoute un filtre pré-authentification solide
6. Envisager de déplacer SSH vers un port non standard : Réduit le bruit des scanners opportunistes, sans constituer un contrôle de sécurité

Capacité de détection KENSAI

• Scan de bannière SSH : KENSAI identifie les versions d'OpenSSH sur tous les actifs exposés à Internet, en signalant les versions 8.5p1–9.7p1 comme vulnérables à CVE-2024-6387
• Scan du réseau interne : Découverte exhaustive des serveurs SSH vulnérables sur les réseaux internes
• Audit de configuration : Vérifie les configurations d'atténuation (LoginGraceTime, AllowUsers, authentification par clé uniquement)
• Validation des correctifs : Confirme l'application du correctif après remédiation
• Contexte d'exposition : Priorise les serveurs SSH exposés à Internet par rapport aux systèmes strictement internes