encore une faille dans sshd

Posté par  . Modéré par Amaury.
Étiquettes :
0
22
avr.
2002
Sécurité
Les versions de SSHd compilées avec le support Kerberos et AFS souffrent d'un nouveau problème de sécurité. Les conséquences peuvent être dangereuses puisque la faille permet un exploit distant pour les versions inférieures à 2.9.9 et un local pour les autres (jusqu'a 3.3).

Il est à noter que si la séparation de privilèges (à laquelle Niels Provos travaille) est activée, aucun accès privilégié n'est possible...

Aller plus loin

  • # cool

    Posté par  (site web personnel) . Évalué à 1.

    Il a téléchargé et testé la version 3.3 avec ipot !

  • # Systèmes affectés

    Posté par  (site web personnel) . Évalué à 10.

    La news d'origine dit : 1. Systems affected: All Versions of OpenSSH compiled with AFS/Kerberos support and ticket/token passing enabled contain a buffer overflow. Ticket/Token passing is disabled by default and available only in protocol version 1. Ca fait à mon avis beaucoup moins de systèmes touchés

    • [^] # Re: Systèmes affectés

      Posté par  . Évalué à 10.

      et comme les dernieres versions de OpenSSH supportent aussi la version 1 du protocole...

      • [^] # Re: Systèmes affectés

        Posté par  (site web personnel) . Évalué à 10.

        La partie importante c'est "Ticket/Token passing is disabled by default". Si la version 1 du protocole n'était pas supportée il n'y aurait pas cette faille à ce que j'ai compris...

        • [^] # Re: Systèmes affectés

          Posté par  . Évalué à 3.

          >Si la version 1 du protocole n'était pas supportée il n'y aurait pas cette faille à ce que j'ai compris... Tu insinues que si on amputait le logiciel, il serait plus sécurisé ? mauvais esprit, changer esprit

        • [^] # Re: Systèmes affectés

          Posté par  (site web personnel) . Évalué à 10.

          Le problème ne concerne que la version 1 du protocole et que si le Ticket/Tocken est active, ce qu'il n'est pas par défaut. Donc pour être converné par la faille, il faut utiliser le protocole version 1 et il faut avoir activé le Ticket/Token machin "à la main".

    • [^] # Re: Systèmes affectés

      Posté par  (site web personnel) . Évalué à 10.

      les questions sont maintenant c'est quoi ces "Ticket/Token passing" et dans les distribs, est ce que c'est activé ou pas la partie kerberos...

      • [^] # Re: Systèmes affectés

        Posté par  . Évalué à 10.

        Comme le dit la news, "ticket/Token passing" se refere a kerberos (et AFS qui se marie bien avec kerberos). En gros si j'ai bien compris, ssh peut utiliser les systèmes d'autentification de kerberos (qui sont tres bien AMHA). Dans la terminologie kerberos, on parle de ticket et de token qui passent de machines en machines (une machine server de ticket ...). Bref ssh doit pouvoir forwarder de rebond en rebond ces autentifications kerberos si on lui demande gentiment, comme il le fait avec ses propres clefs et un ssh-agent. Pour moi c'est clair. Sont impactés ceux qui ont compilé ssh avec le support kerberos et qui l'ont configuré pour propager les "clefs kerberos" de machines en machines.

  • # Encore !!!

    Posté par  . Évalué à -7.

    He oui, c'est encore une application codée en C. Et pas par des loosers. Si on virait le C/C++ et qu'on faisait des vrais bugs (comportement, algo etc..) et pas des bugs inhérents au langage (pb de mémoire essentiellement) ? Surtout en sécurité (protocoles/cryptos) y'a moyen de faire des conneries autrement qu'avec la mémoire ! Virer les langages de merde est l'étape la plus petite et la plus simple vers la qualité. Et mon morpion dressé est d'accord avec moi.

    • [^] # Re: Encore !!!

      Posté par  (site web personnel) . Évalué à -1.

      Oulah! On n'a pas pris sa petite pilule aujourd'hui. Ca va pas de tenter de relancer un troll pareil?

    • [^] # Re: Encore !!!

      Posté par  . Évalué à 0.

      Et hop dans le troll, mais bon... Ca va changer de la tribune en ce moment. Donc je voulais juste dire que les super langages qu'ont des systemes de gestion de la memoire automatiques ont besoin d'une VM pour exister. Et en quoi tu l'ecris la VM?

      • [^] # Re: Encore !!!

        Posté par  . Évalué à -1.

        C'est quoi le rapport ? ça t'oblige à écrire OpenSSH en C sous prétexte que le bootstrapping de ton compilo a été démarré en C ? gcc est écrit en C que je sache, pas directement en assembleur. Le processus est démarré, on peut écrire des compilateurs et des VM dans les langages qu'on veut.

      • [^] # Re: Encore !!!

        Posté par  (site web personnel) . Évalué à 4.

        Et en quoi tu l'ecris la VM? c'est pas une VM mais un GC (garbage collector).

    • [^] # Re: Encore !!!

      Posté par  . Évalué à 4.

      Les développeurs d'OpenSSH n'ont pas l'intention de changer de language de sitôt, malgré tous les efforts de persuasion que tu pourra déployer. Cependant, rien n'empêche qui que ce soit de développer une alternative écrite dans le language de son choix. Si tu veux une implémentation ssh libre, et non écrite en C, il te suffit de trouver une équipe de développeurs intéressés et de se mettre au travail, tout simplement...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.