Faille dans OpenSSH 2.5.x et 2.9.x

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
28
sept.
2001
Sécurité
Cette faille permettrait d'obtenir un accès depuis une machine non autorisée en utilisant l'option 'from' en utilisant des clés RSA et DSA dans le fichier "authorized_keys2"



Un patch est dispo ou vous pouvez passer en 2.9.9.


Toutefois ce bug n'est pas encore dans le bug report de openssh.


Note du modérateur: Ce bug n'affecte que la version 2 d'OpenSSH, la distribution Debian n'est pas affectée par ce problème (version 1.2.3).

Aller plus loin

  • # Debian Sid

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

    la distribution Debian n'est pas affectée par ce problème (version 1.2.3).

    Attention tout de même car il y a des packages ssh2 dans la sid. Je dis ça car je sais qui y a un grand nombre de personnes qui l'utilise ici (à la fois la sid et ssh2 :)
    • [^] # Re: Debian Sid

      Posté par  . Évalué à 6.

      Effectivement, il est assez courant d'utiliser SSH2 sur une Sid (malheureusement ?:) Cependant, on ne peut pas dire que la Sid en elle-même contienne des paquets SSH2, puisque la licence a été jugée (à raison:), trop restrictive pour permettre une inclusion dans main.
      Les paquets de SSH2 sont donc dans non-free, et de ce fait on ne peut pas dire qu'ils fassent partie de Debian... Souvenez-vous de la longue flamewar sur la suppression du répertoire non-free: non-free ne fait _pas_ partie de Debian, ce sont un ensemble de paquets généreusement hébergés par Debian (et généreusement maintenus par des développeurs Debian (ou par qa comme SSH2, bien sûr:)).

      Bon, ok, j'avoue, c'est un peu du chipotage, mais bon, faut bien s'occuper quand on est malade :-)

      Toujours est-il que ça montre encore une fois que les logiciels libres ne sont pas plus sujets aux alertes de sécurité, au contraire :-]
      • [^] # Re: Debian Sid

        Posté par  . Évalué à 10.

        Oui, mais non. On parle là de OpenSSH empaqueté sous le nom de ssh dans Debian,
        alors que le nom du paquet SSH est ssh-nonfree. Ouf!

        Stable/potato n'est pas touchée (ssh 1.2.3 seulement).
        En revanche woody/testing (2.5.2p2) et sid/unstable (2.9p2) ont le problème.
        Qui n'est tout de même pas d'une gravité extrême...
        • [^] # Re: Debian Sid

          Posté par  . Évalué à 1.

          Au temps pour moi. Ça m'apprendra à poster avec 40 de fièvre (39.4, j'exagère), et en lisant la moitié de la news en travers et en louchant.

          Le commentaire du dessus portait à confusion, SSH2 != OpenSSH2 dans mon esprit, donc bon...
          Reste que de fait SSH2 n'est pas dans Debian :-)
  • # arg!

    Posté par  . Évalué à 0.

    le FTP d'openbsd est full.. quelqu'un a une url d'un mirror à jour ?
  • # Y'a aussi un autre trou

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

    Il y a quelques jours dans la bugtraq, quelqu'un a décrit un autre problème de sécurité :
    ssh dispose d'un système de restriction de commandes (par exemple on peut limiter un utilisateur à faire un "ssh user@host ls"), mais lorsque la machine dispose d'un serveur sftp, cette restriction peut etre bypassée.
    Donc méfiance pour ceux qui utilisent sftp...
    • [^] # Re: Y'a aussi un autre trou

      Posté par  . Évalué à 1.

      beh faut se passer de sftp
      suffit d'utiliser MC aka MidnightCommander...
      il permet de browser des repertoires avec ssh 1....
      en gros ... exit ssh 2....
  • # 4 years...

    Posté par  . Évalué à 3.

    Va-t-on considérer cela comme un "remote hole", et donc mettre fin à la longue série de 4 ans sans faille ? C'est triste tout de même :-(
    • [^] # Re: 4 years...

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

      Ce n'est pas un remote hole, car il faut toujours s'authentifier. C'est juste la restriction par IP qui ne marche pas correctement, pas le système d'authentification...
    • [^] # Re: 4 years...

      Posté par  . Évalué à 0.

      Euuuuh il me semble qu'il y a eu de vrais holes auparavent... ils sont discrets chez open :)
      • [^] # Re: 4 years...

        Posté par  . Évalué à 2.

        Nous avons eu des trous de securite "recemment", comme en temoignent certains de nos erratas, mais aucun n'etait exploitable a distance.

        Donc, toujours 4 ans sans vulnerabilite exploitable a distance dans l'installation par defaut...
    • [^] # Re: 4 years...

      Posté par  . Évalué à 3.

      Si je me souviens bien il y a eu un remote hole il n'y a pas si longtemps que ça (un overflow sur un calcul de CRC pouvant amener un malloc(0) et l'exécution de code arbirtaire: http://securityfocus.com/bid/2347(...) )
  • # il faut avoir une IP autorisée et une clé privée quand meme

    Posté par  . Évalué à 10.

    en lisant les détails sur bugtraq:

    http://cert.uni-stuttgart.de/archive/bugtraq/2001/09/msg00259.html(...)

    on voit que les utilisateurs sont en principe
    identifiables par leur clé publique asymétrique
    ET par leur IP
    ici le controle d'IP d'une clé s'applique à celui d'une autre clé
    moralité: il faut quand meme avoir une ip autorisée
    pour une autre clé, at avoir la bonne clé privée
    pour rentrer
    bref, seul un de vos "amis" peut se faire passer pour un autre de vos amis, s'il a la clé privé de l'autre (peu probable)
    • [^] # Re: il faut avoir une IP autorisée et une clé privée quand meme

      Posté par  . Évalué à 10.

      De plus ce bug n'agit semble t'il que si vous utilisez des clefs de type différent (RSA ...).

      Enfin, ce bug est bloquant puisque le champ "from:" de la dernière clef est utilisé pour toutes les clefs. Difficile de ne pas le remarquer (les premières clefs ne fonctionnant pas si elles viennent de l'@IP normale).

      En clair, si ce bug n'a pas été vu avant c'est parce que la fenetre d'activation est tres petite, si petite que personne ne s'y était heurté (sinon il l'aurait vu tout de suite).

      Conclusion: c'est un BUG oui, mais pas vraiment un problème de sécurité. (c'est quand même un bug con !!)
  • # Debian-à foutre...

    Posté par  . Évalué à -7.

    Note du modérateur: Ce bug n'affecte que la version 2 d'OpenSSH, la distribution Debian n'est pas affectée par ce problème (version 1.2.3).

    C'est sympa de prévenir les gens que la Debian n'est pas affectée, mais y'a pas que la Debian sur cette planète. Y'a quand même d'autres distribs qui sont utilisées, en principe, par plus de gens que la Debian.

    En gros, je trouve que cette "Note du modérateur" n'a rien à voir ici avec cette news. Ca fait genre:
    "Renault rappelle toutes les Safranes au garage suite à des problèmes rencontrés sur les ordinateurs de bord.

    Note du modérateur: La voiture de mon grand-père n'est pas affectée par cette anomalie."

    Voila, c'était mon (petit) coup de gueule du jour.
    • [^] # Re: Debian-à foutre...

      Posté par  . Évalué à 4.

      Pis c'est bien connu que la version 1.2.3 d'OpenSSH est exempt de tout bug ...

      Rien qu'utiliser le protocole 1.5 de ssh est une faute de sécurité évidente.
      • [^] # Re: Debian-à foutre mais Backporte !

        Posté par  . Évalué à -2.

        chez security.debian.org
        ils ont que ça à foutre !

        sérieusement un utilisateur de debian stable (potato)
        a le choix entre upgrader ses paquets en mettant un peu de
        testing (très peu risqué) ou de unstable (peu risqué) dans son apt

        ou bien encore de mettre à jour
        UNIQUEMENT les bugs de sécurités en mettant security.debian.org dans son apt (les corrections de sécurité des nouvelles versions sont backportées vers les anciennes versions considérées comme plus stables)

        c'est ça le choix selon debian !

        qui n'a jamais eu une partie de son systeme broken
        à cause d'une nouvelle version incompatible d'un logiciel ?

        on peut donc choisir d'avoir à la fois la sécurité ET la stabilité.
    • [^] # Re: Debian-à foutre...

      Posté par  . Évalué à -6.

      Voila, c'était mon (petit) coup de gueule du jour.

      Petit mais ridicule quand meme.
    • [^] # Re: Debian-à foutre...

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

      la Note du modérateur n'est pas hors-sujet du tout, je vois pas quel interet il y aurait a mettre "redhat affectee, mandrake affectee, suse affectee, ..."

      il precise juste quels SSH n'ont pas ce probleme...
    • [^] # Re: Debian-à foutre...

      Posté par  . Évalué à -2.

      Nan, y'a pas que Debian et alors ? C'est tjs bon de preciser que ceux qui possedent une Popato n'ont pas à faire un apt-get update/upgrade !
      C'est plus simple que de dire "Redhat 7.0/7.1, Mandrake truc, Suse budule, etc.." sont affectées par le probleme, nan ?

      Quant à ta comparaison avec la voiture du grand pere, j'aurais plustot ecris :


      Renault rappelle au garage ces voitures suite à des problèmes rencontrés sur les ordinateurs de bord.


      Note du modérateur: Toutes sauf les Avantime qui ne sont pas affectées.


      On a pas dit que la version de untel n'etait pas affectée, on a donné une série...

      enfin bon... chacun son interpretation de ce que le modero pense...

      Nico
  • # debian, ssh et les socks...

    Posté par  . Évalué à 0.

    A l'attention de ceux qui se servent ou veulent se servir des socks (proxies) avec ssh et debian :







    Dans la liste des packages on trouve un ssh-socks qui permet l'utilisation d'un proxy sock (4 ou 5) pour établir une connection.



    Ca peut être bin pratik toudmeme mais bon c evidemment OpenSSH et pas ssh not bon ami...







    Au début, j'ai été désapointé mais en cherchant bien, le paquet ssh 1.... permet tres bien tout seul de se servir de ce genre de feature.







    Voilou c'était juste une tite info au passage...
    • [^] # Re: debian, ssh et les socks...

      Posté par  . Évalué à -1.

      Tu

      pourrais



      pas




      écrire





      plus




      espacé ?
      • [^] # Re: debian, ssh et les socks...

        Posté par  . Évalué à -2.

        Après le clavier qui se blo le


        clavier


        qui


        fait


        des


        retours


        chariot


        tout


        seul.
      • [^] # Re: debian, ssh et les socks...

        Posté par  . Évalué à -2.

        desolé mais je n'ai pas fais "return" plus que toa...
        juste une question de browser..... de la m$*ù£ê je tedis......
        j'en profitais pour faire un tit test...
    • [^] # Re: debian, ssh et les socks...

      Posté par  . Évalué à 3.

      Euh, ssh-socks est la version "socksifiée" de ssh-nonfree et non OpenSSH.

      La solution libre pur jus, c'est dante + ssh. dante est un "wrapper",
      qui "socksifie" à la volée (socksify ssh).
      Autre possibilité, tsocks.
      • [^] # Re: debian, ssh et les socks...

        Posté par  . Évalué à 2.

        Exact. Faire juste attention à ne pas mettre ssh en suid-root, sinon socksify ne marchera pas (il utilise LD_PRELOAD).

        Pour changer cette option: dpkg-reconfigure ssh

        Autre solution: utiliser "socksify nc" comme ProxyCommand, cela permet en plus d'avoir automatiquement le support du socks pour les machines externes et pas pour les machines internes. Il faut pour cela rajouter ces lignes dans le fichier de conf de ssh (et installer netcat):
        Host *.sf.net *.sourceforge.net
        ProxyCommand socksify nc %h %p
  • # Concernant le bug report...

    Posté par  . Évalué à 5.

    ... Il n'est pas sur que cette faille apparaisse un jour dans le bug report...
    C'est le cas pour de nombreux bugs (parfois minuscules) trouvés dans OpenSSH par un utilisateur ou un codeur qui feuillette les sources. Le plus connu etant quand même un problème vraiement connu, qui fait pourtant parti des bases de la crypto, mais qui n'est toujours pas résollu. Il est très bien expliqué dans un article sur Linux Mag HS spécial securité... Il s'aggit d'utiliser un canal pour diffuser des infos et autres... Je ne rentrerais pas dans les détails techniques, mais vous trouverez tout ce dont vous aurez besoin sur le net ou dans linux-mag.
    Mais bon, vu que le bug de cette news commence à faire parler de lui, il vas peut-être quand même apparaitre dans le bug report.

Suivre le flux des commentaires

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