La vulnérabilité est critique, mais difficile à exploiter.
La vulnérabilité CVE-2024-6387 est critique par sa conséquence
(exécution de code à distance sans compte) mais aussi parce qu’elle touche toutes les
versions d’OpenSSH depuis la version 8.5 (publiée en mars 2021). Elle a été corrigée
dans la version 9.8.
Par contre elle est complexe à exploiter. Qualys dit avoir réussi l’exploiter contre un
système Linux 32 bits après de 6 à 8 heures d’essais continus (temps nécessaire pour
satisfaire la race condition puis pour contourner la protection ASLR). L’attaque contre
un système Linux 64 bits nécessiterait encore plus de temps (à notre connaissance, elle
n’a pas été réalisée). Mais il est possible que de nouvelles techniques d’attaques
soient découvertes et rendent l’attaque plus facile.
Les systèmes affectés sont Linux et *BSD (sauf OpenBSD)
Le projet OpenSSH indique que la vulnérabilité est exploitable uniquement sur les
systèmes utilisant la glibc (GNU C Library). Il s’agit donc normalement uniquement des
systèmes Linux et BSD (netBSD, FreeBSD, etc.).
Les systèmes comme Solaris, AIX, … ou même Windows ne sont donc en principe pas affectés.
Nous ferons une mise à jour s’il s’avère que certains de ces systèmes sont aussi touchés
(par exemple dans le cas où la glibc aurait été installée sur ces systèmes).
Empêcher ou détecter les tentatives attaques
Nous avons mentionné dans notre avis plusieurs palliatifs pouvant empêcher l’attaque
(installer fail2ban ou SSHGuard, changer le paramètre LoginGraceTime).
Splunk a publié un
article intéressant le 02/07/2024 sur ce sujet :
- Il donne plusieurs méthodes d’atténuation (Mitigation Strategies),
- Il indique aussi que les tentatives d’attaques vont générer un pic de message syslog
du type « Timeout before authentication ».
Un programme d’exploitation contesté
Un programme d’exploitation (nommé « 7etsuo-regreSSHion.c ») a été publié dès
le 01/07/2024. L’efficacité de cet exploit est contestée par certains (par exemple par un membre de
l’équipe Qualys). Mais l’article de Splunk (cité ci-dessus) analyse certaines
parties de cet exploit sans mettre en doute son efficacité.
