Analyse de la vulnérabilité "ssh-agent" de OpenSSH

A la mi-novembre, un correctif concernant OpenSSH (pour les versions inférieures à 2.3.0) a été publié sur Internet. Ce correctif résout une vulnérabilité qui n'était pas connue jusqu'à présent. Le CERT-IST n'a pas publié d'avis pour cette vulnérabilité car il a jugé que le problème était mineur, et il est donc simplement cité à la rubrique " Failles n'ayant pas fait l'objet d'avis " du présent bulletin. Cette vulnérabilité nous donne l'occasion de présenter quelques fonctions avancées de SSH (celles impactées par la vulnérabilité) et d'expliciter notre analyse de la criticité du problème qui vient d'être corrigé.

Le correctif pour OpenSSH concerne 2 fonctions particulières de SSH :

• le "X11 forwarding",
• et la fonction d'agent d'authentification ("ssh_agent").

Le " X11 forwarding " de SSH

Dans la plupart des installations de SSH, la fonction de " X11 forwarding " est activée car elle apporte aux utilisateurs une solution sécurisée pour utiliser X11. Dans ce cas en effet, lorsqu'un client ssh se connecte à un serveur SSH, ce dernier configure automatiquement l'environnement du processus lancé par le client sur le serveur pour que le trafic X11 généré passe par le canal chiffré SSH liant ces deux machines.

Ainsi, lorsque la commande " ssh -f machine_cible xterm " est lancée :

• il apparaît sur l'écran local une fenêtre "xterm" (fenêtre console),
• l'application "xterm" s'exécute sur la machine cible,
• et le trafic X11 entre les deux machines est protégé à l'intérieur d'un canal SSH chiffré.

Ce type de fonctionnement est très confortable. Il est cependant dangereux dans le cas ou le serveur SSH est corrompu (par exemple, si la machine hébergeant ce serveur est compromise et que le serveur SSH d'origine a été remplacé par un clone malicieux). En effet, un serveur SSH modifié peut utiliser cette fonctionnalité (canal X11 créé par ssh) pour lire le contenu de l'écran de l'utilisateur à son insu (écoute du serveur X11). Pour éviter ce danger, un client SSH peut être configuré pour ne pas activer le " X11 forwarding " (et ne pas utiliser X11) quand il s'adresse à un serveur SSH dont la confiance n'est pas maîtrisée.

L'agent d'authentification de SSH

Lorsque SSH est utilisé en mode " authentification RSA " (utilisateurs authentifiés au moyen de clés publiques et de clés secrètes), le client SSH a besoin de demander à l'utilisateur la " pass phrase " pour lire la clé secrète de l'utilisateur (cette clé est stockée sous forme chiffrée dans le fichier " $HOME/.ssh/identity " par défaut).

Si l'utilisateur veut éviter de taper cette " pass phrase " de multiples fois au cours d'une session de travail, il peut activer la fonction "ssh_agent". Dans ce cas :

• l'utilisateur crée un agent d'authentification (lancement du processus "ssh_agent")
• puis lui donne une seule fois la "pass phrase" (en utilisant la commande "ssh_add"),

A chaque fois qu'une authentification est ensuite requise, le client SSH délègue automatiquement cette tâche à l'agent d'authentification, et il n'est plus nécessaire de demander à l'utilisateur sa " pass phrase ".

Ce mécanisme est sécurisé :

• seuls les clients SSH lancés par l'utilisateur peuvent dialoguer avec l'agent d'authentification (la communication se fait par un pipe UNIX, et les clients SSH de l'utilisateur sont en fait des descendants du processus père "ssh-agent").
• l'agent d'authentification ne communique jamais la clé secrète (ou la "pass phrase") à un tiers : il se substitue au client SSH pour les phases d'authentification où la clé secrète est nécessaire.

Ce mécanisme de délégation est également utilisé quand l'utilisateur se connecte successivement sur plusieurs machines. Par exemple si un client SSH se connecte sur le serveur S1, puis de ce serveur sur le serveur S2, l'authentification sur ce second serveur " remonte " vers le serveur S1, puis vers le client SSH pour finalement être traité par l'agent d'authentification.

L'agent d'authentification implémente donc un système comparable à un " single sign-in " : l'utilisateur donne une seule fois sa " pass phrase " (à l'agent d'authentification local), puis se déplace librement (sans avoir à fournir à nouveau cette " pass phrase ") sur tous les serveurs SSH sur lesquels sa clé publique est présente.

Le principe d'un agent d'authentification est très confortable. Cependant, tout comme dans le cas du " X11 forwarding ", il est également dangereux dans le cas où un serveur SSH est corrompu. Une fois qu'un utilisateur a établi une connexion SSH avec ce serveur, ce dernier peut en effet, à l'insu de l'utilisateur, utiliser l'identité de l'utilisateur pour ouvrir des connexions (qui seront authentifiées automatiquement par l'agent d'authentification) vers d'autres serveurs SSH où cet utilisateur est connu. Pour éviter ce danger, il est possible de configurer un client SSH pour lui interdire de propager une demande d'authentification vers l'agent d'authentification.

La vulnérabilité corrigée par SSH 2.3.0

Les dangers mentionnés précédemment sont connus depuis longtemps et SSH fournit pour y faire face un moyen de configurer le client SSH pour refuser le " X11 forwarding " et la fonction d'agent d'authentification.

La vulnérabilité qui a été découverte sur OpenSSH (pour les versions inférieures à 2.3.0) est qu'un serveur SSH malicieux peut forcer le client OpenSSH à effectuer du " X11 forwarding ", ou à propager une demande d'authentification, même si le client est configuré pour refuser ces actions. Ce comportement est définitivement anormal. Cependant cette vulnérabilité n'est exploitable que dans le cas ou un serveur SSH corrompu est accédé.

Cet élément relativise beaucoup la gravité de cette vulnérabilité dans la mesure où la fonction première de SSH est d'établir un canal de communication sûr, entre des machines qui ont auparavant été sécurisées. L'éventualité qu'un serveur SSH soit corrompu est certes toujours possible, mais dans ce cas il est de toutes façons difficile de garantir que les canaux SSH ne seront pas (d'une façon ou d'une autre) utilisés pour propager la compromission (en particulier, les " pass phrases " pour les clés secrètes stockées sur une machine compromise peuvent être volées en espionnant les utilisateurs locaux). Ce danger de propagation intrinsèque à SSH justifie une fois de plus que des couples " clé publique / clé privée " différents soient utilisés dans le cas où on accède à des systèmes de sensibilité (ou de niveau de sécurité) différents.