Vulnérabilité OpenSSH

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
25
juin
2002
Sécurité
ISS, peu après avoir dévoilé le problème sur Apache, avait annoncé qu'ils travaillaient sur une faille d'un autre logiciel libre (en annonçant cette fois-ci que la démarche serait un peu différente !).
Encore Bind ? Sendmail ? Squid ?
Et bien non, OpenSSH... :-(

Les détails sur la faille ne sont pas encore connus mais on sait d'ors et déjà de la bouche de Théo de Raadt lui-même qu'elle sera exploitable à distance, sauf si la séparation de privilège récemment apparue est activée (« UsePrivilegeSeparation yes » dans sshd_config). Peu de distributions Linux proposent cette option pour le moment mais j'espère sincèrement qu'ils vont tous s'atteler pour que ce soit le cas avant la semaine prochaine, date fatidique à laquelle seront dévoilés les détails de l'exploit (et je pense qu'un exploit pas forcèment de Gobbles ne tardera pas à suivre...)

Plus de détails sur LinuxSecurity.com

Note d'un autre modérateur : voir sur debianplanet.org la source apt Debian pour avoir les paquets ssh et apache corrigés pour Woody, ainsi que Mozilla 1.0

Aller plus loin

  • # Euh, y a un trou là...

    Posté par  . Évalué à 10.

    En effet sur le site d'OpenBSD on a dans la section patches la notice suivante :
    http://www.openbsd.org/errata.html(...)

    Traduction :
    Un bug non (encore) rendu public existe dans OpenSSH pour lequel aucun patch n'est prévu -- aucun pacth n'existe pour l'instant!
    Néamoins une mise à jour vers OpenSSH 3.3 avec l'option UsePrivilegeSeparation activée permet de bloquer cette faille.
    Il est conseillé à tous les utilisatuers de mettre à jour immédiatement, et de garder un oeuil sur la sortie de OpenSSH 3.4 qui aura lieu lundi et qui contiendra une vrai correction de cette faille.

    Trois mondes s'effondrent :
    1°) Il va falloir mettre à jour des BSD, comme dans "c'est obligatoire", "ca vaut mieux", "on prend des risques sinon"
    2°) J'ignore si la faille existe dans le SSH propriétaire, mais si ce n'est pas le cas ca risque d'avoir des conséquences désastreuses sur certains newsgroups et forums.
    3°) OpenBSD est fourni de base avec OpenSSH, donc les versions "anciennes" avaient ce trou de sécurité. Donc il y a un trou de sécurité dans l'installation par défaut d'OpenBSD, on a juste mis 5 ans à le trouver.

    Ceci étant c'est le deuxième exploit d'OpenSSH en un mois (un autre impliquait l'utilisation d'YP avec Netgroup dans la base des mots de passes). C'est pas bon pour ma paranoia ca :).

    Kha
    ---
    OpenBSD Power quand même na!

    • [^] # Re: Euh, y a un trou là...

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

      1°) Il va falloir mettre à jour des BSD, comme dans "c'est obligatoire", "ca vaut mieux", "on prend des risques sinon"
      3°) OpenBSD est fourni de base avec OpenSSH, donc les versions "anciennes" avaient ce trou de sécurité. Donc il y a un trou de sécurité dans l'installation par défaut d'OpenBSD, on a juste mis 5 ans à le trouver.

      Je rappelle qu'il y a le bug apache aussi, qui a finalement été exploité sur les *nix 32 bits. Et qui permet en exploitant d'autres pb de prendre le root.

      • [^] # Re: Euh, y a un trou là...

        Posté par  . Évalué à 8.

        Tout a fait d'accord pour le bug Appache. Mais Apache ne fait pas partie de la base install d'OpenBSD, donc rien à dire. Bon c'est du pinaillage d'accord, mais il y a un paquet de package OpneBSD qui ont des failles. OpenBSD ne s'engage que sur l'install de base point.


        Kha
        ---
        Paranoia Complex.

        • [^] # Re: Euh, y a un trou là...

          Posté par  . Évalué à 10.

          Non, apache fait partie du système de base et n'est pas lancé par défaut.

          Par contre, sshd l'est, et effectivement les cinq ans tomberont à la publication de la vulnérabilité.

          • [^] # Re: Euh, y a un trou là...

            Posté par  . Évalué à 9.

            Heureusement que ce ne sont pas des hackers qui gardent la faille pour eux!
            on aurait été confiant dans openssh ..
            et on aurait bien eu l'air ***
            s'en donc finis des 5 ans sans trou à distance !
            le compteur va t'il rester bloqué a 5 ?
            qd j'ai reçu le sms cette nuit sur le "trou"
            j'ai été bien vert et surpris, déja apache :(

    • [^] # Re: Euh, y a un trou là...

      Posté par  . Évalué à 10.

      le fait de dire que "aucun patch n'est prévu" est totalement faux et c'est une traduction totallement biaisée...
      Ils sont en train de bosser sur une version de ssh qui résoud le problème mais n'ont pas encore fini !

      Et en attendant ils préviennent que la séparation de privilèges de OpenSSH ne permet pas de choper un root direct qd l'exploit sortira (officiellement parce qu'apparemment certains sont deja en train de s'en donner a coeur joie...).

      La version corrigée de OpenSSH est prévue pour la semaine prochaine.

      • [^] # Re: Euh, y a un trou là...

        Posté par  . Évalué à 4.

        Je ne pense pas que ma traduction soit fausse ou biaisée. Et de plus il est vrai qu'aucun patch n'est prévu. Une nouvelle version n'est pas un patch.

        la version originale dit bien :

        An (as yet) undisclosed bug exists in OpenSSH which a patch is not forthcoming for yet -- no patch exists yet!

        Il est plus que probable que la nouvelle version risque d'entrainer des reconfigs, et peut être même un réaudit complet pour les systèmes "sensibles". Rien à voir avec l'installation d'un patch ou l'on sait que le mode de fonctionnment n'a pas bougé et que l'on peut garder les mêmes fichiers de configs et la même architecture de sécurité.

        Kha
        ---
        Un brin pinailleur aujourd'hui

        • [^] # Re: Euh, y a un trou là...

          Posté par  . Évalué à 2.

          pas pour le moment ne veut pas dire pas du tout.
          Je trouve normale qu'ils résolvent deja le problème sur la version courante puis qu'ils patchent les versions precedentes...
          chaque chose en son temps !

    • [^] # Re: Euh, y a un trou là...

      Posté par  . Évalué à 10.

      Ceci étant c'est le deuxième exploit d'OpenSSH en un mois (un autre impliquait l'utilisation d'YP avec Netgroup dans la base des mots de passes). C'est pas bon pour ma paranoia ca :).

      Ce qui est intéressant, c'est que, juste après le précédent problème dans OpenSSH, les développeurs ont mené une réflexion sur comment empêcher une faille future de profiter des privilèges de sshd, et c'est pourquoi privsep a été développé.

      Savoir que la première faille trouvée après l'introduction de privsep n'est pas utilisable si privsep est activé prouve que privsep est plus qu'un concept académique...

  • # Séparation des privilèges

    Posté par  . Évalué à 10.

    La séparation des privilèges est activée par défaut dans les rpms openssh-3.3 que Mandrake vient de sortir.

    Quelqu'un qui va enfin pouvoir comencer à bosser après avoir mis à jour une dizaine de machines :-(

  • # \o/ ouéééé

    Posté par  . Évalué à -10.

    c'est la fete en ce moment pour les trous de securités
    bon au final je vais peut etre repasser a la gentoo parceque sur la lfs, recompiler tout les trois jours apache ou ssh ca commence a etre lourd!!!

    allez hop emerge openssh

    -1 car ma vie

  • # Réponse chez Debian

    Posté par  . Évalué à 10.

    Voici l'alerte de sécurité chez Debian [http://lists.debian.org/debian-security-announce/debian-security-an(...)]. Les non anglophobes devraient avoir peur en la lisant.

    En effet, il semblerait que même si ISS a changé de méthode (hum ...), ça reste caché ... De plus, la nouvelle version ne corrige pas le problème, mais ne permet la compromission que d'un compte non privilégié. Cela ouvre donc la porte à l'utilisation de tout escalation de privilège ou tout exploit local !

    De plus, vu le peu de temps donné, ainsi que le manque d'informations sur la faille font qu'aucun paquet corrigé n'est disponible pour la potato. De même, la version pour la woody n'a pas été testée par l'équipe QA et peut donc tout casser, en plus de ne pas être totalement fonctionnelle (compression indisponible sur certains systèmes, PAM indisponible) !

    Bien sûr, il ne faut pas critiquer quelqu'un qui divulgue une faille de sécurité sur un LL, mais là je trouve qu'ils poussent le bouchon un peu trop loin. D'abord l'affaire apache, maintenant openSSH, je commence vraiment à apprécier de moins en moins ISS ...

    • [^] # Re: Réponse chez Debian

      Posté par  . Évalué à 10.

      Perso ca fonctionne bien sur les deux woody que j'ai upgradé cette nuit ... j'espere que les nouvezaux paquets fonctionneront pour tout le monde ;)

      Par contre c'est vrai que c'est vrai qu'on a pas l'habitude de voir des process sshd apartenant à des utilisateurs.

    • [^] # Re: Réponse chez Debian

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

      D'abord l'affaire apache, maintenant openSSH, je commence vraiment à apprécier de moins en moins ISS ...
      Bah c'est cool, ils bossent indirectement pour améliorer les LL, on va pas leur en vouloir parce qu'ils leur cherchent la petite bête... Dans l'ensemble, ils effectuent quand même une bonne partie du boulot en découvrant la faille et en l'annonçant, même s'ils ne fournissent ni patches ni informations complètes. Après tout, ce n'est peut-être pas leur boulot de sécuriser les logiciels.
      Ce qu'il faut voir c'est qu'au final, on a des LL plus sécurisés et tout le monde en profite, ce qui ne serait pas le cas avec des softs proprios.

      • [^] # Re: Réponse chez Debian

        Posté par  . Évalué à 8.

        Moi, ce que je critique, c'est qu'ils ont fait une annonce alors qu'aucun correctif n'existe. D'après eux, c'est une solution acceptable d'avoir un utilisateur non privilégié d'exploité (ce qui permet par la suite d'utiliser une faille locale pour devenir root). De plus, ils considèrent normal que tout le monde mette à jour leur openSSH avec une version qui n'a pas été testée de manière extensive, et qui surtout n'est pas totalement fonctionnelle. Je me répète, mais la compression et PAM ne fonctionnent pas sur certains systèmes.

        Si ce n'est pas du foutage de gueule, alors défoulez vous avec le [-], mais je ne suis pas de cet avis ...

        • [^] # Re: Réponse chez Debian

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

          La position de Theo de Raadt, d'OpenBSD :

          > Date: Mon, 24 Jun 2002 15:00:10 -0600
          > From: Theo de Raadt <deraadt@cvs.openbsd.org>
          > Subject: Upcoming OpenSSH vulnerability
          > To: bugtraq@securityfocus.com
          > Cc: announce@openbsd.org
          > Cc: dsi@iss.net
          > Cc: misc@openbsd.org

          La suite ici :
          http://lists.debian.org/debian-security/2002/debian-security-200206(...)

        • [^] # Re: Réponse chez Debian

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

          Hum .. perso je préfère etre sur une version pas totalement fonctionnelle qu'une version avec un gros trou de sécu connu (root possible).

          Enfin c'est ton choix mais le conseil de passer à la version plus sécurisé est AMHA un bon conseil.

          Si vraiment tu trouves que ce n'est pas fonctionnel alors tu fermes le service en attendant mieux.

          Apres en effet peut etre qu'ils auraient du l'annoncer plus tard (je le pense) et autrement (ca c'est sur) mais bon, je préfère que ca soit connu de tous (et de moi aussi) plutot qu'il y ai une communauté restreinte au courant qui a pouvoir sur tous mes serveurs (pour peu que ca se diffuse un peu dans les communautés de méchants avant que ca passe dans les alertes de sécu ca peut faire tres mal).

    • [^] # Re: Réponse chez Debian

      Posté par  . Évalué à 10.

      Je pense que, dans le cas de cette faille, tes critiques sur ISS sont injustifiées.

      Une faille dans OpenSSH (et peut-être d'autres implémentations) a été trouvée. Bon. ISS aurait très bien pu contacter l'équipe d'OpenSSH en disant «voilà les gars, vous avez tel trou, on le publie, avec un exploit, dans 48 heures». Or, ils ne l'ont pas fait.

      A la place, la publication de la faille est reportée afin que les gens aient la possibilité de mettre à jour leur OpenSSH, non pas pour corriger le bug (puisque la disponibilité de la correction permettrait à tout un chacun de cuisiner un exploit dans son coin), mais pour le rendre inopérant grâce à privsep.

      Dans un monde parfait, tous les vendeurs auraient fourni des mises à jour d'OpenSSH lundi au plus tard, et la faille aurait été publiée mercredi - c'est ce qui avait été négocié. Comme les vendeurs font de la résistance parce que la faille n'a pas été publiée sur le thème de «j'y croirai quand je me prendrai un exploit dans la figure», il a fallu faire un peu plus de bruit autour de ce problème, et laisser plus de temps avant la publication.

      Dans tout ça, que peux-tu reprocher à ISS? Leur attitude est très correcte jusqu'à présent.

    • [^] # Re: Réponse chez Debian

      Posté par  . Évalué à 0.

      L'alerte donnée lundi dans la nuit sur la tribune était signée (je me souviens pas si il y avait une signature numérique) de Theo, pas d'ISS.

  • # man ssh / UsePrivilegeSeparation

    Posté par  . Évalué à 10.

    cette option n'est pas disponible sur toutes les versions de ssh.

    # man sshd / UsePrivilegeSeparation

    UsePrivilegeSeparation
    Specifies whether sshd separates privileges by creating an un-
    privileged child process to deal with incoming network traffic.
    After successful authentication, another process will be created
    that has the privilege of the authenticated user. The goal of
    privilege separation is to prevent privilege escalation by con-
    taining any corruption within the unprivileged processes. The
    default is ``yes''.

    vous avez bien lu, default is "yes" ...

    • [^] # Re: man ssh / UsePrivilegeSeparation

      Posté par  . Évalué à 9.

      Par défaut, oui, mais pas partout. Ca peut etre le cas pour OpenBSD 3.1 ou le dernier package Mandrake mais c'est très loin d'être la cas dans la plupart des distribs Linux qui ne sont en général meme pas encore passées en version 3.x d'OpenSSH...

    • [^] # Re: man ssh / UsePrivilegeSeparation

      Posté par  . Évalué à 6.


      cette option n'est pas disponible sur toutes les versions de ssh.

      Oui, c'est justement pour ça qu'on demande à tout le monde de passer en OpenSSH 3.3, car c'est justement cette version qui introduit cette option !

      • [^] # Re: man ssh / UsePrivilegeSeparation

        Posté par  . Évalué à 8.

        Oui, c'est justement pour ça qu'on demande à tout le monde de passer en OpenSSH 3.3, car c'est justement cette version qui introduit cette option !

        Non, privsep est plus ancien, mais un gros effort (à cause de l'existence de cette faille) a été fait afin que privsep soit disponibles sur plus de systèmes dans la version portable d'OpenSSH.

        Par contre, à partir d'OpenSSH 3.3, privsep est activé par défaut, ce qui n'était pas le cas avant.

        Un système OpenBSD 3.1 (donc sous OpenSSH 3.2) dont la configuration du sshd a été modifiée afin d'activer privsep, n'est pas plus vulnérable qu'un OpenSSH 3.3.

        • [^] # Re: man ssh / UsePrivilegeSeparation

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

          <a vérifier>
          Il semble que il est quand meme possible d'utiliser la faille de sécurité avec la séparation des privilèges de la version 3.3
          </a vérifier>
          Le mieux est d'attendre la version patchée lundi.

          • [^] # Re: man ssh / UsePrivilegeSeparation

            Posté par  . Évalué à 1.

            T'as lu ça dans France Dimanche ?

            Si on pousse tout le monde à passer à privsep, c'est justement parce que privsep permet de rendre la vulnérabilité inutilisable.

            Elle reste présente, mais ses effets sont suffisamments limités pour qu'elle ne puisse servir à rien.

  • # Boooohhh

    Posté par  . Évalué à 4.

    Peu de temps apres les failles de PHP, c'est maintenant au tour d'Apache, mod_ssl et OpenSSH d'avoir de gros trous de securite. C'est un coup dur pour le logiciel libre, il y en a beaucoup qui n'attendaient que ca pour ricanner et dire que finalement, l'opensource ne valait pas mieux qu'un bon vieux Windows.

    C'est d'autant plus flippant que ces failles sont presentes depuis tres longtemps et viennent seulement d'etre connues.

    Bah apres tout, ca va encourager tout le monde a employer systematiquement des outils comme Lids, GrSecurity et Systrace pour limiter la casse.

    • [^] # Re: Boooohhh

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

      Il n'y a pas de quoi ricaner. Ces failles ont toutes été corrigées extrêmement rapidement, et on ne peut pas en dire autant des failles d'IIS, par exemple...

      • [^] # Re: Boooohhh

        Posté par  . Évalué à 0.


        Il n'y a pas de quoi ricaner. Ces failles ont toutes été corrigées extrêmement rapidement, et on ne peut pas en dire autant des failles d'IIS, par exemple...

        Ou encore de celles de MSIE dont certaines commencent reellement a dater :)

  • # OpenSSH 3.4 est dans les bacs

    Posté par  . Évalué à 2.

    La correction de la faille est disponible avec OpenSSH 3.4,
    arrivé sur http://www.openssh.com(...)

    Les advisories, chez OpenSSH: http://www.openssh.com/txt/preauth.adv(...)
    celui de ISS: http://www.openssh.com/txt/iss.adv(...)

    La vulnérabilité chez Bugtraq: http://online.securityfocus.com/bid/5093(...)
    et non, il n'y a pas d'exploit publié ...

Suivre le flux des commentaires

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