Journal OpenSSH, UseRoaming no

Posté par  . Licence CC By‑SA.
34
14
jan.
2016

Theo de Raadt vient de poster un message assez alarmant sur la liste de distribution openbsd-tech.

D'après les informations glanées ça et là, une faille dans une fonctionnalité non documentée du client OpenSSH permettrait une fuite de donnée importante de la mémoire du client. Par exemple la clé privée utilisée.

Le bug provient d'une fonctionnalité non documenté et active par défaut qui permet au client de relancer à nouveau une connexion SSH en cas de coupure. Pour fonctionner, cette fonctionnalité, doit être disponible sur le serveur or celle-ci n'a jamais été implémentée (ou du moins activée) côté serveur. Afin d'exploiter la faille il faut donc se connecter sur un serveur malicieux ou qui a été compromis.

En attendant la distribution des correctifs, la meilleure chose à faire est d'ajouter la ligne suivante dans le fichier ssh_config:

    UseRoaming no

Affaire à suivre.

  • # Déjà des correctifs

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

    Package : openssh
    CVE ID : CVE-2016-0777 CVE-2016-0778
    Debian bug : 810984

    The Qualys Security team discovered two vulnerabilities in the roaming
    code of the OpenSSH client (an implementation of the SSH protocol
    suite).

    SSH roaming enables a client, in case an SSH connection breaks
    unexpectedly, to resume it at a later time, provided the server also
    supports it.

    The OpenSSH server doesn't support roaming, but the OpenSSH client
    supports it (even though it's not documented) and it's enabled by
    default.

    CVE-2016-0777

    An information leak (memory disclosure) can be exploited by a rogue
    SSH server to trick a client into leaking sensitive data from the
    client memory, including for example private keys.
    CVE-2016-0778

    A buffer overflow (leading to file descriptor leak), can also be
    exploited by a rogue SSH server, but due to another bug in the code
    is possibly not exploitable, and only under certain conditions (not
    the default configuration), when using ProxyCommand, ForwardAgent or
    ForwardX11.
    This security update completely disables the roaming code in the OpenSSH
    client.

    It is also possible to disable roaming by adding the (undocumented)
    option 'UseRoaming no' to the global /etc/ssh/ssh_config file, or to the
    user configuration in ~/.ssh/config, or by passing -oUseRoaming=no on
    the command line.

    Users with passphrase-less privates keys, especially in non interactive
    setups (automated jobs using ssh, scp, rsync+ssh etc.) are advised to
    update their keys if they have connected to an SSH server they don't
    trust.

    More details about identifying an attack and mitigations will be
    available in the Qualys Security Advisory.

    For the oldstable distribution (wheezy), these problems have been fixed
    in version 1:6.0p1-4+deb7u3.

    For the stable distribution (jessie), these problems have been fixed in
    version 1:6.7p1-5+deb8u1.

    For the testing distribution (stretch) and unstable distribution (sid), these
    problems will be fixed in a later version.

    We recommend that you upgrade your openssh packages.

    Further information about Debian Security Advisories, how to apply
    these updates to your system and frequently asked questions can be
    found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Déjà des correctifs

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

      An information leak (memory disclosure) can be exploited by a rogue SSH server to trick a client into leaking sensitive data from the client memory, including for example private keys.

      Si la fuite est dans le client SSH, ceux qui utilisent un agent n’ont a priori pas à craindre pour leurs clefs privées, vu que celles-ci sont dans la mémoire du processus de l’agent et pas dans celle du client proprement dit.

      • [^] # Déjà dans Debian

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

        Une mise à jour de la distribution devrait suffire.

        • [^] # Re: Déjà dans Debian

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

          C'est marrant pour un même correctif, on passe d'un niveau d'urgence haut chez Debian :

          openssh (1:6.0p1-4+deb7u3) wheezy-security; urgency=high
          
            * Non-maintainer upload by the Security Team.
            * Disable roaming in openssh client: roaming code is vulnerable to an
              information leak (CVE-2016-0777) and heap-based buffer overflow
              (CVE-2016-0778).
          
           -- Yves-Alexis Perez <corsac@debian.org>  Wed, 13 Jan 2016 22:35:39 +0100
          

          À un niveau d'urgence moyen chez Ubuntu :

          openssh (1:6.6p1-2ubuntu2.4) trusty-security; urgency=medium
          
            * SECURITY UPDATE: information leak and overflow in roaming support
              - debian/patches/CVE-2016-077x.patch: completely disable roaming option
                in readconf.c.
              - CVE-2016-0777
              - CVE-2016-0778
          
           -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Wed, 13 Jan 2016 10:48:19 -0500
          
      • [^] # Re: Déjà des correctifs

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

        Ou une smartcard (genre une yubikey), ou une clé stocké dans le tpm (https://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly )

        Par contre, CVE-2016-0778 me parait plus grave.

        Je suppose que finalement, ssh client devrait aussi être dans une sandbox, vu qu'il y a pas besoin de grand chose.

  • # Les détails...

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

  • # dropbear SSH

    Posté par  . Évalué à 2.

    est-ce qu'il est impacté et est-ce que cette option existe?

    • [^] # Re: dropbear SSH

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

      Dropbear est une implémentation de SSH (le protocole) qui est totalement indépendante de OpenSSH (l’implémentation dont il est question ici), donc même s’il implémentait la même option de roaming (ce qui n’est sans doute pas le cas, ça a l’air d’être une spécificité d’OpenSSH et non une fonctionnalité standardisée), il ne serait pas impacté.

      • [^] # Re: dropbear SSH

        Posté par  . Évalué à 0.

        Ouais euh ici la faille concerne le client, pas le serveur. Donc dropbear ou pas ça n'a rien à voir, il n'y a pas de client dropbear (afaik).

        "The authentication of the server host key prevents exploitation
        by a man-in-the-middle, so this information leak is restricted
        to connections to malicious or compromised servers."

        Donc le risque c'est d'avoir subit un M-i-M et d'avoir accèpté la clef du serveur malicieux. Où de s'être connecté à un serveur compromis, sans agent-ssh (i.e. avec ssh -i maclef, ou en utilisant la même .ssh/id_rsa partout).

        J'espère que personne ici utilise la même .ssh/id_rsa pour se connecter à différents serveurs ;-) Ċa pue quand même cette faille…

        • [^] # Re: dropbear SSH

          Posté par  . Évalué à 4. Dernière modification le 15 janvier 2016 à 00:20.

          note cela concerne quiconque a utilisé le client OpenSSH, à la louche 90% des utilisateurs (j'en laisse 10 à putty et 0,0001 à lsh et autres gnueries) ET qui s'est connecté une fois sans utiliser un agent ssh (donc soit avec ssh -i maclef ou avec ~/.ssh/id_rsa ce qui correspond aussi à la louche à plus de 90% des utilisations) à un serveur compromis ou malicieux …
          En gros 99% des gens qui utilisent un prestataire d'hébergement (vps, etc.) peuvent changer leurs clefs et auditer tous leurs serveurs… :p

          Ou quiconque qui a subit un MitM et qui a accepté la nouvelle clef du serveur (mais bon là ça veut dire qu'on l'a bien cherché).

          • [^] # Re: dropbear SSH

            Posté par  . Évalué à 2.

            Ou quiconque qui a subit un MitM et qui a accepté la nouvelle clef du serveur (mais bon là ça veut dire qu'on l'a bien cherché).

            Pour les gens à moitié profane, tu peux expliquer? Je croyais que le but d'un mitm, c'était justement que l'utilisateur ne le voit pas. Alors "on l'a bien cherché" ?

            • [^] # Re: dropbear SSH

              Posté par  (Mastodon) . Évalué à 2.

              Je pense qu'il veut dire que celui qui accepte une nouvelle clé les yeux fermés sans se poser de question l'a bien cherché.

              Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

        • [^] # Re: dropbear SSH

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

          Donc dropbear ou pas ça n'a rien à voir, il n'y a pas de client dropbear (afaik).

          Si :

          Dropbear is a relatively small SSH server and client.

  • # Option non-documentée ??

    Posté par  . Évalué à 9.

    La notion d'option non-documentée dans un logiciel comme OpenSSH, connaissant la rigueur de ses développeurs, est assez étonnante. Disons que c'est plus digne d'OpenSSL.

    • [^] # Re: Option non-documentée ??

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

      Si j’ai bien compris, l’oubli c’est surtout celui d’avoir oublié de retirer la feature expérimentale au niveau du client (quand ils l’ont fait au niveau du serveur), pas de la documenter.

      Ce qui est pire en fait, du coup.

    • [^] # Re: Option non-documentée ??

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

      C'est toujours dommage sur un logiciel de ne pas avoir de correspondance entre les options que tu peux passer en ligne de commande/par configuration, les options que tu peux voir lister avec le --help, les options qui sont dans la page de manuel/la doc, et potentiellement les commentaires dans le code correspondant à ces options. Et après l'erreur peut aussi venir de la traduction pas à jour si on consulte les infos dans une autre langue que l'anglais.

Suivre le flux des commentaires

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