Sur LibSSH, une « faille triviale » existait depuis quatre ans
Le 18 octobre 2018 à 10h54
1 min
Internet
Internet
Le Cert-FR explique que la faille réside dans la bibliothèque côté serveur et « permet à un attaquant de provoquer un contournement de la politique de sécurité ». Les versions 0.6 et plus récentes sont concernées.
Le moins que l'on puisse dire, c'est que son exploitation est on ne peut plus triviale : « En envoyant au serveur un message SSH2_MSG_USERAUTH_SUCCESS à la place de SSH2_MSG_USERAUTH_REQUEST auquel le serveur s'attendait pour lancer l'authentification, l'attaquant pouvait s'authentifier avec succès sans aucune information d'identification ».
Des correctifs ont évidemment été déployés pour avec LibSSH 0.8.4 et 0.7.6. Bien qu'utilisant LibSSH, GitHub affirme ne pas être impacté grâce à la manière dont il exploite cette bibliothèque.
La version 0.6 ayant été publiée en janvier 2014, cela fait plus de quatre ans que le contournement des protections pouvait être réalisé de cette manière.
Le 18 octobre 2018 à 10h54
Commentaires (12)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 18/10/2018 à 10h30
Ca sent le contournement du dev pour faire ses test qui n’a pas été retirer au moment du commit
" />
Le 18/10/2018 à 11h04
Ca sent surtout la forfanterie “given enough eyeballs every bug is shallow” qu’on se ramasse dans la poire à chaque fois.
Le 18/10/2018 à 11h32
C’est-à-dire plus spécifiquement ?
Le 18/10/2018 à 11h50
J’ai voulu être bref, on me demande d’être disert, alors je me lance…
Le souci c’est que ça donne du grain à moudre aux adversaires FUD de l’open source : “d’une part il n’y a pas moins de bugs que dans le propriétaire, mais en plus n’importe qui peut les exploiter simplement en lisant le code”.
Le grand avantage annoncé de l’open source est précisément que, les sources étant librement disponibles, les bugs ne résistent pas longtemps aux scrutations des personnes intéressées. Après heartbleed, voici encore une fois la preuve que ce n’est vrai que dans un univers parallèle au nôtre.
Ensuite vient le fait qu’on fait essentiellement confiance aux tests automatisés. Le catastrophique “ça compile donc c’est bon” d’antan a fait place à “les tests automatisés passent, donc c’est bon” pas tellement meilleur. Les tests montrent que le code ne fait pas moins qu’annoncé, ils sont incapables de démontrer qu’il ne fait pas plus qu’annoncé. Or les protocoles de sécurité sont extrêmement sensibles à ces petits à-côté.
Le 18/10/2018 à 11h55
Oui, enfin pour quelque chose comme libSSH avoir des tests de blocage de tentative de connexion c’est pas plus mal.
Mais c’est vrai qu’en dehors de monkey testing c’est difficile de tester absoluement tous les cas. On va tester le blocage si mauvais password mais oon va pas penser au cas où l’utilisateur fait semblant d’être déjà authetifié.
Le 18/10/2018 à 12h16
Le 18/10/2018 à 12h20
Le 18/10/2018 à 13h12
Mettrais pas mes machines à jour, YOLO comme disent les jeunes.
" />
" />
En même temps, libssh n’est installé sur aucune
Le 18/10/2018 à 13h53
ouais pour le coup, ça aide un peu
" />
Le 18/10/2018 à 13h57
Je ne suis pas sûr que cette lib soit beaucoup utilisée.
Le 18/10/2018 à 17h27
Le 18/10/2018 à 18h10
Chez moi sur la même ubuntu que toi, en plus de cette libssh2, j’ai bien la libssh concernée qui est utilisée par l’unique programme :
remmina : remote desktop client for GNOME desktop environment
Je pense qu’en tant que client (et pas serveur), il n’est pas pas concerné.
La lib a de toute façon bien été mise à jour.