Des chercheurs ont découvert une importante faille de sécurité dans OpenSSH. Il s’agit en fait d’une régression : la faille a été réintroduite en 2020, alors qu’elle avait été corrigée en 2006. Au vu du danger entrainé par la faille, critique, il est recommandé de mettre à jour rapidement.
Chez Qualys, une équipe de chercheurs a averti d’une faille critique dans OpenSSH. Estampillée CVE-2024-6387 et nommée RegreSSHion, elle peut permettre l’exécution d’un code à distance, sans authentification, sur tous les systèmes Linux basés sur la bibliothèque glibc (implémentation open source de la bibliothèque standard C). Le tout avec les droits administrateurs. Plusieurs distributions ont déjà émis des bulletins de sécurité sur le problème, notamment Debian, ArchLinux, Oracle Linux, Red Hat et Ubuntu.
« Cette vulnérabilité, si elle est exploitée, peut conduire à une compromission totale du système où un attaquant peut exécuter un code arbitraire avec les privilèges les plus élevés, ce qui entraîne une prise de contrôle complète du système, l'installation de logiciels malveillants, la manipulation de données et la création de portes dérobées pour un accès persistant », décrit ainsi Bharat Jogi, directeur de la recherche sur les menaces chez Qualys.
L’exploitation pourrait « faciliter la propagation dans le réseau, permettant aux attaquants d'utiliser un système compromis comme point d'ancrage pour traverser et exploiter d'autres systèmes vulnérables au sein de l'organisation ».
Une ancienne faille de retour
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (19)
#1
#1.1
#1.2
"Vous avez corrigez RegreSSHion ?"
plutôt que :
"Vous avez corriger la CVE-2024-6387 ?"
On fait le même avec les tornades et les ouragans alors que le nom "scientifique" attribué est à coucher dehors.
#1.4
Si on parle de HeartBleed, tout le monde (domaine concerné, j'entend) comprend la faille importante d'OpenSSL d'il y a une décennie (d'ailleurs pour une mode, ça fait longtemps).
Si on parle de Log4Shell, tout le monde se souvient d'une astreinte fin 2021/début 2022 pour suivre et remédier la faille du framework de journalisation log4j de Java.
Par contre si on évoque CVE-2021-44228 ou CVE-2014-0160...
Et c'est de toute façon une pratique courante. Dans un service IT, tu vas toujours entendre parler de "l'incident sur les commandes" et pas du "ticket 1247423".
Historique des modifications :
Posté le 03/07/2024 à 14h32
J'ajoute à cela que ça permet de garder un historique parlant.
Si on parle de HeartBleed, tout le monde comprend la faille importante d'OpenSSL d'il y a une décennie (d'ailleurs pour une mode, ça fait longtemps).
Si on parle de Log4Shell, tout le monde se souvient d'une astreinte fin 2021/début 2022 pour suivre et remédier la faille du framework de journalisation log4j de Java.
Par contre si on évoque CVE-2021-44228 ou CVE-2014-0160...
Et c'est de toute façon une pratique courante. Dans un service IT, tu vas toujours entendre parler de "l'incident sur les commandes" et pas du "ticket 1247423".
#1.5
Et c'était premier degré.
#1.6
C'est l'exception qui confirme la règle, où le nom technique est plus connu et parlant que le nom commercial (dans le cas du Firewire) ou de communication.
(après y'a aussi une question d'ego)
#1.3
Historique des modifications :
Posté le 03/07/2024 à 13h57
C'est pourtant bien mieux pour savoir de quoi on parle. Pas d'accord utilisateur 30627 ?
#1.7
#1.8
#1.9
Par contre l'avatar créé par Flock l'est.
En vrai, il s'est passé quoi ?
#1.10
#1.11
#1.12
Historique des modifications :
Posté le 05/07/2024 à 09h35
Si ça les fait rentrer en kernel panic, tant mieux : ils auront figé et ne feront plus rien jusqu'au prochain reboot et on pourra continuer de négliger en rond
#2
#3
Après SSH c'est tellement sensible, surtout après la frayeur de la backdoor d'il y a qq semaines que était rentré en testing...
#3.1
#4
#5
Par ce que entre le logingrace à 0 et ça sur des serveurs interne pas sur que ce soit vraiment mieux
#6