regreSSHion : la race condition qui a remis SSH sur la table

L'histoire en deux phrases

En 2006, OpenSSH corrige CVE-2006-5051 : une race condition signal-handler-not-async-safe dans sshd. En 2020, une refactorisation (commit 752250c) réintroduit accidentellement le bug dans OpenSSH 8.5p1. Qualys le redécouvre quatre ans plus tard.

La mécanique

sshd configure un SIGALRM qui tire si l'utilisateur n'a pas authentifié dans LoginGraceTime secondes (par défaut 120 s). Quand le signal tire, le handler appelle des fonctions non async-signal-safe (notamment des routines de logging glibc) - c'est ce que la norme POSIX interdit, parce que le contexte du handler peut interrompre une autre fonction au milieu d'un état non cohérent.

L'attaquant :

1. Ouvre une connexion SSH.
2. Laisse expirer le LoginGraceTime au moment exact où sshd se trouve dans une fonction malloc/free côté glibc.
3. Le handler interrompt cet état et provoque une corruption du heap exploitable.

Par chance pour les défenseurs, c'est très difficile à exploiter : Qualys annonce ~10 000 tentatives nécessaires sur Debian 32-bit, plusieurs heures sur les configurations 64-bit testées. Mais en 2024, "plusieurs heures" est une fenêtre tout à fait acceptable pour un attaquant patient.

Résultat : RCE en tant que root, pré-authentification, sans interaction utilisateur, sur n'importe quel sshd exposé.

Versions impactées

• OpenSSH 8.5p1 jusqu'à 9.7p1 inclus, liés à glibc (Linux principalement).
• OpenSSH < 4.4p1 : vulnérables si non patchés contre CVE-2006-5051.
• OpenSSH 4.4p1 → 8.5p1 : non vulnérables (le bug original avait été corrigé).
• OpenBSD : non vulnérable.
• macOS, FreeBSD : non concernés (libc différente).

Patcher

| Distribution | Version corrigée | | --- | --- | | OpenSSH amont | 9.8p1 (1ᵉʳ juillet 2024) | | Ubuntu 22.04 / 24.04 | mises à jour openssh-server du 1ᵉʳ juillet | | Debian 12 | 1:9.2p1-2+deb12u3 | | RHEL 9 / Rocky 9 | openssh-8.7p1-38.el9_4.1 | | Fedora 39 / 40 | openssh-9.6p1-... | | Amazon Linux 2 / 2023 | ALAS2-2024-2585 / ALAS2023-2024-643 |

Mitigation immédiate sans patch : LoginGraceTime 0 dans /etc/ssh/sshd_config. ⚠️ Cela rend votre sshd plus tolérant aux DoS lents (clients qui n'authentifient jamais), à mettre en balance.

# Vérifier la version
ssh -V
sshd -V 2>&1 | head -1

# Forcer LoginGraceTime à 0 en attendant le patch
sed -i 's/^#\?LoginGraceTime.*/LoginGraceTime 0/' /etc/ssh/sshd_config
systemctl restart sshd

Pourquoi c'est intéressant pour un défenseur

Cette CVE rappelle plusieurs choses :

1. Les régressions arrivent. Même les projets aussi sérieux qu'OpenSSH. Vos outils SAST/DAST ne suffisent pas - il faut des tests de régression sécurité sur les CVE historiques.
2. SSH internet-facing est une dette. En 2024, un sshd exposé en clair sur 22 sans bastion ni VPN est une posture qui doit avoir une justification métier.
3. LoginGraceTime est une primitive d'attaque. Plusieurs CVE OpenSSH historiques ont utilisé ce point - durcissez ou bornez son rôle.
4. Surveillez vos logs sshd[XXXX]: Timeout before authentication for ... - pic = tentatives de race condition.

• Kreomnis