Journal OpenSSH, UseRoaming no

Posté par Spack le 14 janvier 2016 à 18:07. Licence CC By‑SA.

Étiquettes :

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 GG (site web personnel) le 14 janvier 2016 à 18:28. É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 gouttegd le 14 janvier 2016 à 18:58. É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 Sytoka Modon (site web personnel) le 14 janvier 2016 à 19:01. Évalué à 1.
    
    Une mise à jour de la distribution devrait suffire.
    - [^] # Re: Déjà dans Debian
      
      Posté par Bruno Ethvignot (site web personnel) le 15 janvier 2016 à 17:30. É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 Misc (site web personnel) le 16 janvier 2016 à 15:00. É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 Tonton Th (Mastodon) le 14 janvier 2016 à 19:26. Évalué à 10.

Bonne lecture
# dropbear SSH

Posté par Le Gab le 14 janvier 2016 à 21:57. Évalué à 2.

est-ce qu'il est impacté et est-ce que cette option existe?
- [^] # Re: dropbear SSH
  
  Posté par gouttegd le 14 janvier 2016 à 23:42. É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 benja le 15 janvier 2016 à 00:05. É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 benja le 15 janvier 2016 à 00:17. É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 Maclag le 15 janvier 2016 à 13:29. É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 Psychofox (Mastodon) le 15 janvier 2016 à 13:33. É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é.
    - [^] # Re: dropbear SSH
      
      Posté par gouttegd le 15 janvier 2016 à 08:02. É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 Antoine le 14 janvier 2016 à 23:56. É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 louiz’ (site web personnel) le 15 janvier 2016 à 00:24. É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 Benoît Sibaud (site web personnel) le 15 janvier 2016 à 11:33. É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.