Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

Publié le 2 juillet 2024
CVE-2024-6387 — “RegreSSHion”. Race condition dans le handler SIGALRM de sshd, déclenchable à distance, sans credentials. La cible finale : root sur la machine. L’exploitation est lente (jours plutôt qu’heures sur la plupart des cibles) et nécessite un payload spécifique au binaire — mais le PoC public a démontré que c’est tout à fait faisable.

​
L’histoire derrière le bug

CVE-2006-5051 avait été corrigée en 2006. En 2020, une refactorisation du code de logging d’OpenSSH a réintroduit la même condition. Personne ne l’a vue pendant quatre ans. C’est Qualys qui l’a déterrée en juin 2024 — d’où le nom “RegreSSHion”, contraction de regression et SSH.

​
Le mécanisme

sshd impose un délai maximum (LoginGraceTime, 120 secondes par défaut) pour qu’un client termine son authentification. Si le délai expire, le noyau envoie un SIGALRM au process, qui déclenche un handler nommé sigdie. Ce handler appelle des fonctions de logging (syslog(), etc.) qui ne sont pas async-signal-safe — elles peuvent prendre des verrous, allouer de la mémoire, manipuler des structures globales. Si l’attaquant cale précisément l’expiration du timer pendant que sshd est lui-même en train de manipuler ces structures (typiquement pendant une opération de logging concurrente), il déclenche une corruption de la heap. Avec assez de tentatives et un payload finement ajusté, cette corruption se transforme en exécution de code dans le process sshd privilégié.

​
Pourquoi l’attaque est lente sans être théorique

  • Il faut des dizaines de milliers de tentatives pour gagner la race.
  • Chaque tentative doit attendre l’expiration du LoginGraceTime.
  • Le payload doit être taillé pour la version exacte d’OpenSSH et la libc de la cible.
Sur un Debian glibc 32 bits, Qualys a démontré l’exploitation en ~6-8 heures. Sur un 64 bits récent, ils estiment 6-8 jours par cible. C’est trop lent pour du spray and pray, mais largement raisonnable pour une attaque ciblée — et l’industrialisation de l’exploit progresse.

​
Êtes-vous concerné ?

Versions affectées (Linux glibc) :
  • OpenSSH 4.4p1 → 8.5p1 : non concernées (la régression a été introduite après).
  • OpenSSH 8.5p1 → 9.7p1 : vulnérables.
  • OpenSSH 9.8p1 et au-delà : corrigées.
Vérification rapide : 
ssh -V

​
Patcher

Suivez le tracker de votre distribution :
DistributionVersion corrigée
Ubuntu Jammy (22.04)1:8.9p1-3ubuntu0.10
Ubuntu Mantic (23.10)1:9.3p1-1ubuntu3.6
Ubuntu Noble (24.04)1:9.6p1-3ubuntu13.3
Debian Bullseye (11)1:8.4p1-5+deb11u3
Debian Bookworm (12)1:9.2p1-2+deb12u3
Debian Sid1:9.7p1-7

​
Mitigation temporaire

Si vous ne pouvez pas patcher tout de suite, vous pouvez supprimer la fenêtre de race en imposant LoginGraceTime 0 dans /etc/ssh/sshd_config : 
LoginGraceTime 0
Puis recharger : 
sudo systemctl reload ssh
Cette mitigation vous expose à un déni de service trivial : un attaquant peut ouvrir des connexions TCP qui ne s’authentifient jamais et épuiser les slots de pré-authentification de sshd. À n’utiliser qu’en dernier recours, le temps que le patch passe.
Mesures de réduction de surface complémentaires, applicables sans perte de service :
  • Restreindre l’accès SSH par firewall à des IP ou ranges connus.
  • Activer Match + AllowUsers pour réduire la surface des comptes joignables.
  • Mettre du fail2ban sur l’auth log pour ralentir les bursts de tentatives.

​
Vérifier après patch

# La version doit être au-delà des plages vulnérables
sudo sshd -V 2>&1 | head -1

​
En résumé

Une régression discrète, exploitable, qui rappelle que les patches anciens méritent une régression-test. Patcher est rapide, le coût opérationnel est minime, et le risque résiduel d’une RCE root non authentifiée justifie de ne pas attendre. Pour toute question, ouvrez un ticket depuis votre espace client OnetSolutions.