Dans quelle mesure la récente vulnérabilité UseRoaming SSH est-elle exploitable?
J'ai récemment entendu parler de n bogue grave dans un client OpenSSH ( CVE-2016-0777 et CVE-2016-0778 ) que si je comprenais bien, cela pourrait entraîner l'exécution de code à distance. Comment serait-il difficile pour un homme du milieu actif d'exploiter cela?
Comme l'a dit Steve Sether, ce n'est pas une attaque de l'homme du milie .
Est-ce dangereux?
- Dans certains cas, des attaques par dépassement de tampon sont possibles.
- Vos clés SSH privées peuvent être divulguées à un attaquant.
Selon la page:
L'itinérance SSH permet à un client, en cas de rupture inattendue d'une connexion SSH, de la reprendre ultérieurement, à condition que le serveur le prenne également en charge. Le serveur OpenSSH ne prend pas en charge l'itinérance, mais le client OpenSSH le prend en charge (même s'il n'est pas documenté) et il est activé par défaut.
Pour commencer, cette fonctionnalité est activée par défaut dans OpenSSH. Pire encore, il n'est pas documenté dans la page de manuel ssh_config(5).
Notez qu'il s'agit de deux exploits:
- CVE-2016-0777
- Une fuite d'informations (divulgation de mémoire) peut être exploitée par un serveur SSH non autorisé pour inciter un client à divulguer des données sensibles de la mémoire client, y compris par exemple des clés privées.
- CVE-2016-0778
- Un débordement de tampon (conduisant à une fuite de descripteur de fichier), peut également être exploité par un serveur SSH escroc, mais en raison d'un autre bogue dans le code n'est peut-être pas exploitable, et uniquement dans certaines conditions (pas la configuration par défaut), lors de l'utilisation de ProxyCommand, ForwardAgent ou ForwardX11.
En ce qui concerne l'attaque par dépassement de tampon, notez qu'elle n'est vulnérable que dans certaines conditions, lorsque vous avez ProxyCommand et ForwardAgent ou ForwardX11 activé. Ce ne sont pas des options par défaut, donc bien qu'il soit possible qu'elles ne soient pas exploitées dans la grande majorité des cas, c'est c'est possible.
Dans le cas d'une attaque réussie par dépassement de tampon, supposez que tout ce qui est accessible par le client SSH est violé.
Plus d'information
Je lirais le Analyse Qualys . Cet article expliquera cette attaque dans les moindres détails bien mieux que la plupart d'entre nous, y compris moi-même.
pourrait provoquer l'exécution de code à distance
Aucune exécution de code à distance. Pas d'homme au milieu, comme cela a été éclairci par Mark. Tout est expliqué dans le analyse Qualys comme déjà lié.
Mais en bref:
La chose vulnérable est l'implémentation de la fonction Roaming dans le client . Le client stocke le tampon de ne pas envoyer d'octets si la connexion est suspendue. Le serveur vulnérable et mal conçu peut forcer le client à renvoyer plus que ce qui est dans le tampon et donc il pourrait obtenir votre clé privée, si elle est réellement stockée sur certaines adresses autour (devrait pas être dans le cas normal).
L'analyse est présentée sur une version spécifique (openssh-6.4), qui est presque nulle part utilisée aujourd'hui et la plupart des cas d'utilisation ne sont pas directement applicables aux applications actuellement utilisées versions. Certains des problèmes sont également spécifiques aux systèmes BSD, où la mise à zéro de la mémoire ne fonctionnait pas comme prévu. Je n'ai pas réussi à obtenir les clés des systèmes actuels que j'avais.
Le plus gros problème est la chose qu'il y avait même une telle chose, fonctionnalité non documentée , qui était vulnérable sous cette forme. Et qu'il était là depuis si longtemps (introduit en 2004) et qu'il était activé par défaut. Cela pourrait avoir été mal utilisé dans le passé, mais pas à l'insu de l'utilisateur (si la session était interactive). Si vous voyez
[connection suspended, press return to resume]
Je suppose que tu deviendrais un peu méfiant.