Les détails de la faille d'OpenSSH

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
26
juin
2002
Sécurité
ISS vient de publier sur Bugtraq les détails de la faille d'OpenSSH.
Il s'agit d'un problème dans le mécanisme d'authentification "challenge-response".

Apparemment si OpenSSH est compilé sans les options SKEY ni BSD_AUTH, la vulnérabilité n'est pas exploitable.
De meme, utiliser la ligne suivante dans /etc/ssh/sshd_config résoudrait d'après eux le problème :
ChallengeResponseAuthentication no

Ben maintenant il reste plus qu'à tester tout ça, régler les quelques problèmes de conf engendrés.
Ca a quand même l'air moins dangereux que ce qui était annoncé précédemment et surtout moins difficile à règler (c'est pas une raison pour pas mettre a jour !).

Remarque : ISS met a disposition un outil pour tester si OpenSSH est vulnérable.

Note du modérateur : OpenSSH 3.4 est sorti (merci à falbala pour l'info)

Aller plus loin

  • # Euh...

    Posté par  . Évalué à -10.

    Ça m'a surtout pas l'air d'être la même...

    http://online.securityfocus.com/archive/1/278755/2002-06-23/2002-06(...)

    • [^] # Re: Euh...

      Posté par  . Évalué à -10.

      Ah si en fait... j'avais trop lu en diagonale :-p

  • # Quelques remarques

    Posté par  . Évalué à 10.

    C'est OpenSSH 3.4 (et pas OpenBSD) qui est sorti; il règle quelques autres problèmes, donc devrait être utile à installer.

    La ligne en question est à "no" dans pas mal de distrib (Mdk 8.2, RedHat 7.1, etc...) et ne devrait pas trop gener (qui utilise des SKey avec OpenSSH? sans parler de BSD_Auth sous Linux). Il est à noter que pour ceux que cette config dérange OpenSSH 3.3 avec Privilege Separation, ou encore mieux OpenSSH 3.4 sont une solution.

    DaFrog.

    • [^] # Re: Quelques remarques

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

      La ligne en question est à "no" dans pas mal de distrib (Mdk 8.2, RedHat 7.1, etc...)

      ... mais à "yes" dans les RedHat 7.2 et 7.3

  • # le record d'OpenBSD, c'est fini !

    Posté par  . Évalué à 10.

    Hé oui, le slogan sur la première page de http://www.openbsd.org(...) vient de passer de Five years without a remote hole in the default install! à One remote hole in the default install, in nearly 6 years!, et c'est Theo De Raadt qui a lui même fait le changement ( http://www.openbsd.org/cgi-bin/cvsweb/www/index.html(...) ).

    Enfin ca reste "not too bad", comme le message de commit le dit !

  • # Une seule ligne à changer

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

    Je suis bien content qu'il n'y ait qu'une seule ligne de configuration à changer. Mettre à jour, c'est bien beau, mais il me semble que tout leur code « provilege separation » est encore bien neuf, bien frais, et pas testé au grand large.

    Les dévelopeurs semblent avoir été bien alarmistes en demandant au monde entier de se mettre à jour sur leur dernière version.

    • [^] # Re: Une seule ligne à changer

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

      En fait, je trouve même qu'ils ont dépassé les limites du raisonnable :-( Si j'avais su qu'il y avait une solution aussi facile, je ne me serais jamais amusé à upgrader en catastrophe ma distrib' vers un paquet peu testé et réalisé à la va vite. Le mainteneur du paquet n'a pas apprécié non plus (je cite l'annonce sur security.debian.org : « [Theo de Raadt et ISS] refusent de fournir des détails sur cette vulnérabilité et conseillent à la place à tout le monde de mettre à jour [...] Puisque les détails du problème n'ont pas été divulgués, nous avons été forcés de passer à la dernière version ». Parmi les problèmes engendrés, le support PAM ne fonctionne pas parfaitement dans cette version).

      La question que je me pose est : si cette ligne suffit vraiment à rendre inopérante la vulnérabilité (et l'advisory sur BugTraq ne dit pas autre chose : « les administrateurs peuvent ôter cette vulnérabilité en désactivant le paramètre d'authentification défi-réponse »), pourquoi ne pas avoir lancé un appel du genre « administrateurs, veuillez changer ceci dans votre sshd.conf » ? Pourquoi avoir poussé les gens à faire une update qui de toute manière n'enlève pas la cause du problème (la vulnérabilité est toujours présente, les risques de passer root sont juste réduits) ? Cette attitude me laisse vraiment perplexe. Ai-je raté un épisode ? Quelqu'un y comprend-il quelque chose ?

      Envoyé depuis mon PDP 11/70

      • [^] # Re: Une seule ligne à changer

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

        Ca indiquait aux gens ou regarder pour une faille.

        Cela dit il aurait aussi pu dire que ca n'affectait que openssh 3.

        Il est clair que cette histoire risque d'avoir des retombées pendant un bon bout de temps

      • [^] # Re: Une seule ligne à changer

        Posté par  . Évalué à 10.

        Pour en rajouter une couche, Debian n'était pas vulnérable (aussi bien Potato que Woody ou Sid) car le package ssh n'est compilé avec aucune des deux options BSD_AUTH ou SKEY.

        Theo a donc réussi à forcer un bon paquet de gens à passer à OpenSSH 3.3 + PrivSep, il est fort...

        Merci, Theo.

      • [^] # Re: Une seule ligne à changer

        Posté par  . Évalué à 10.

        (disclémeure : je suis suffisamment mouillé dans le déroulement de ces événements pour que mon opinion ne soit pas objective)

        Si j'avais su qu'il y avait une solution aussi facile...

        Eh oui, mais si tu l'avais su, d'autres personnes l'auraient su. Et au lieu d'avoir un exploit non publié, on aurait eu une foultitude d'exploits en circulation, dont un dans Télé 7 jours.

        Pour la première fois dans l'histoire d'OpenSSH, la vulnérabilité pouvait facilement être inhibée d'une façon simple (privsep), qui présentait l'avantage de ne pas attirer l'attention sur la partie du code vulnérable. D'où les efforts faits pour inciter les gens à utiliser privsep.

        Malheureusement, si privsep était validé et éprouvé sous OpenBSD, le support privsep dans la version portable était un ton en-dessous (absent pour bon nombre de systèmes, non fonctionnel sous d'autres comme Linux 2.2 par exemple). Et devant le manque de réaction des éditeurs de ces systèmes, il a été demandé un délai supplémentaire à ISS, et une annonce aussi vague que possible a été faite, afin de renforcer l'incitation à passer à privsep. Oui, par certains côtés, cela ressemble à crier «au loup» - surtout quand il n'est pas possible de divulguer plus d'informations sous peine de réduire le plan à néant.

        Malheureusement, alors que bon gré mal gré les différents vendeurs s'alignaient sur OpenSSH 3.3, et que les problèmes soulevés par privsep sur certains systèmes commençaient a être découverts et corrigés, ISS a estimé qu'attendre lundi était trop, et a insisté pour publier la vulnérabilité, avec les détails cette fois, dans le courant de mercredi. Il a donc fallu sortir OpenSSH 3.4 plus tôt que prévu, alors que les packages 3.3 commençaient seulement a être utilisés... ce qui donne vraiment une mauvaise impression d'ensemble, pour sûr.

        Maintenant, en commençant à prendre du recul, comment ce problème aurait-il pu être traité autrement ?

        Publier la vulnérabilité avec les détails en même temps qu'une version corrigée d'OpenSSH, c'était lancer une nouvelle course à la mise à jour par rapport à la fabrication des exploits de cette faille.

        Prendre le temps d'avoir un support privsep éprouvé sur la plupart des systèmes du marché, c'était impossible avec ISS insistant pour rendre publique la vulnérabilité le plus rapidement possible.

        Des choix ont été faits. Il n'est pas possible de satisfaire tout le monde, mais dans l'ensemble, les choses auraient pu bien plus mal se passer...

        Maintenant que tu connais plus de données du problème, prends quelques jours de recul, et demande-toi ce que tu aurais fait à notre place.

        • [^] # Re: Une seule ligne à changer

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

          Hum. Bon, tu me pardonneras de ne pas attendre quelques jours pour répondre, mais y a des trucs que je pige pas :-)

          > Eh oui, mais si tu l'avais su, d'autres personnes l'auraient su. Et au lieu d'avoir un exploit non publié, on aurait eu une foultitude d'exploits en circulation, dont un dans Télé 7 jours.

          Oui, mais en attendant, tout le monde aurait pu se prémunir immédiatement. Qui vous dit que les gars d'ISS ont été les premiers à trouver cette faille ?

          > Malheureusement, si privsep était validé et éprouvé sous OpenBSD, le support privsep dans la version portable était un ton en-dessous (absent pour bon nombre de systèmes, non fonctionnel sous d'autres comme Linux 2.2 par exemple).

          C'est justement ce qui me choque ! On nous a dit de mettre à jour -- ce qui signifiait ici se causer des problèmes -- alors que des solutions beaucoup plus simples (et qui marchaient partout, elles) étaient disponibles. Je n'ai rien contre OpenBSD, mais là ça ressemble vaguement à une punition collective (« mettez donc à jour vers la bonne version. Et tant pis si elle est imparfaite sur votre OS »). Et tout ça pour quoi ? Car, en fin de compte, tous ceux qui avaient un minimum de jugeote ont certainement upgradé dès la publication de l'existence du problème, tandis que les autres, j'en mettrais ma main à couper, ne l'ont toujours pas fait, malgré le « délai de grâce » apporté par ce stratagème. Je n'arrive donc pas à voir l'intérêt de l'opération...

          > Publier la vulnérabilité avec les détails en même temps qu'une version corrigée d'OpenSSH, c'était lancer une nouvelle course à la mise à jour par rapport à la fabrication des exploits de cette faille.

          Pourquoi une nouvelle course à la mise à jour, alors qu'il suffisait de désactiver une option ? Quant à la fabrication des exploits, je maintiens que les chapeaux noirs qui vont essayer des exploits d'ici quelques temps trouveront toujours des machines non mises à jour et non reconfigurées (et probablement pas beaucoup moins que si l'on s'était épargné tout ce ramdam).

          > Prendre le temps d'avoir un support privsep éprouvé sur la plupart des systèmes du marché, c'était impossible avec ISS insistant pour rendre publique la vulnérabilité le plus rapidement possible.

          Vrai. Mais encore une fois, c'est dit dans l'optique de privsep comme la seule bonne solution. Et je m'inscris en faux, comme dirait l'autre ;-)

          > Des choix ont été faits. Il n'est pas possible de satisfaire tout le monde, mais dans l'ensemble, les choses auraient pu bien plus mal se passer...

          Tout à fait. Dans l'ensemble, je suis toujours de l'avis que l'équipe d'OpenSSH fait du très bon boulot. C'est juste que, question rélations publiques cette fois-ci c'était pas top. Mais qui aime bien châtie bien, hein ? :-) Et en tout cas, merci pour la réponse !

          Envoyé depuis mon PDP 11/70

        • [^] # Re: Une seule ligne à changer

          Posté par  . Évalué à -2.

          > Maintenant que tu connais plus de données du problème, prends quelques
          > jours de recul, et demande-toi ce que tu aurais fait à notre place.

          Laisse tomber, ce n'est qu'un utilisateur, comment veux-tu qu'il comprenne que tu as bien fait de l'obliger à passer à une version pourrie alors qu'il aurait suffi qu'il modifie un fichier de configuration pour se prémunir ?

          • [^] # Re: Une seule ligne à changer

            Posté par  . Évalué à 2.

            > Laisse tomber, ce n'est qu'un utilisateur, comment veux-tu qu'il comprenne
            > que tu as bien fait de l'obliger à passer à une version pourrie alors
            > qu'il aurait suffi qu'il modifie un fichier de configuration pour se prémunir ?

            Et l'admin qui a une politique de sécurité qui impose une autentificiation de
            type challenge/response, il fait quoi ? Il met son service en rideau ?

            • [^] # Re: Une seule ligne à changer

              Posté par  . Évalué à 2.

              Desactiver cette option n'etait pas la seule possibilite, il peut soit appliquer un patch de 20 lignes, soit mettre a jour. Mais il vaut mieux ne rien lui dire, a ce con d'admin, de toute facon il ne comprend rien a la securite, il vaut mieux l'obliger a upgrader. D'ailleurs la prochaine fois, j'espere que cette fine equipe va mettre a disposition un upgrade sous forme de binaires seulement pendant quelques jours (pour *BSD uniquement, bien sur, les autres systemes, c'est de la merde), puis les sources, afin de ne pas devoiler la faille.

Suivre le flux des commentaires

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