> ## 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.

# RegreSSHion (CVE-2024-6387) : RCE non authentifiée dans OpenSSH

> Une régression d'une faille de 2006 ré-apparaît dans OpenSSH récent et permet une exécution de code à distance avec les droits root, sans authentification.

*Publié le 2 juillet 2024*

<Warning>
  **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.
</Warning>

## 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 :

```bash theme={null}
ssh -V
```

## Patcher

Suivez le tracker de votre distribution :

| Distribution          | Version 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 Sid            | `1: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` :

```text theme={null}
LoginGraceTime 0
```

Puis recharger :

```bash theme={null}
sudo systemctl reload ssh
```

<Note>
  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.
</Note>

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

```bash theme={null}
# 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](https://onetsolutions.net).