Produits affectés

Plusieurs produits Cisco qui comprennent le support pour un serveur SSH sont vulnérables si le serveur SSH est activé. Les routeurs Cisco et les Switches Catalyst utilisant les versions affectées de la plate forme logicielle Cisco IOS cité plus bas ont été confirmé vulnérable.

Les produits de Cisco qui contiennent la fonctionnalité de serveur SSH confirmés ne pas être vulnérable incluent :

* Cisco Catalyst Switches exécutant Cisco CatOS

* Les concentrateurs Cisco de la série VPN3000

* Cisco PIX Firewall

* Cisco Secure Intrusion Detection System (NetRanger) appliance

* Cisco Secure Intrusion Detection System Catalyst Module

* Cisco SN5400 Series Storage Routers

* CiscoWorks 1105 Wireless LAN Solution Engine (WLSE)

* CiscoWorks 1105 Hosting Solution Engine (WLSE)

Détails

Une suite des paquets ouvrés a été développée pour tester des implémentations du protocole de l'interpréteur de commandes interactif (SSH). Si le serveur SSH a été activé, plusieurs des cas d'essai causent un redémarrage obligatoire du dispositif avant que le procédé d'authentification ne soit appelé. Chaque fois qu’une tentative de connexion de SSH est faite à un dispositif de Cisco exécutant la plate forme logicielle Cisco IOS avec un des paquets ouvrés, et que le serveur de SSH est activé sur le dispositif, le dispositif redémarre.

Le dispositif de serveur de SSH est disponible dans les versions suivantes de la plate forme logicielle Cisco IOS: 12.0S, 12.0ST, 12.1T, 12.1E,

12.2, 12.2T, 12.2S. Toutes les versions qui ont le dispositif de serveur SSH sont vulnérables quand le serveur SSH est activé en émettant la commande "crypto key generate rsa" en mode configuration.

Tous les produits exécutant des versions vulnérables de la plate forme logicielle Cisco IOS exepté le Cisco 3550 qui redémarrera automatiquement et reprendra le service après la panne totale. Le Cisco 3550 ne redémarrera pas, et exigera une intervention manuelle pour reprendre un traitement normal.

Cette faille de la plate forme logicielle Cisco IOS est répertoriée dans DDTS CSCdz60229.

Impact

La vulnérabilité peut être exploitée pour rendre un produit affecté indisponible pendant plusieurs minutes le temps du redémarrage du dispositif.

Une fois qu'il a repris le traitement normal, le dispositif est encore vulnérable et peut être forcé à redémarrer à plusieurs reprises.

Versions et correctifs de plate forme logicielle :

Un tableau présentant toutes les versions étant affectées, et leurs correctifs disponibles peuvent être trouvés à l’adresse ci dessous :

http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml#Software.

Workarounds :

Les workarounds consistent à désactiver le serveur SSH, retirer SSH comme méthode d'accès à distance, permettre seulement aux centres serveurs de confiance de se relier au serveur, et bloquer le trafic SSH au dispositif complètement par l'intermédiaire des mécanismes externes.

Attention : Le workaround suivant aura des effets secondaires indésirables pour les sessions d'IPSEC qui se terminent sur le dispositif qui utilisent les paires principales de RSA pour l'authentification de dispositif, ou qui utilisent des certificats basés sur ces paires principales de RSA. Des sessions d'IPSEC utilisant d'autres méthodes d'authentification ne seront pas affectées.

Pour l'IOS de Cisco le serveur de SSH peut être désactivé en appliquant la commande " crypto key zeroize rsa " en mode configuration. Le serveur de SSH est activé automatiquement lors de la génération d'une paire principale RSA. La mise à zéro des clés de RSA est la seule solution de désactivation complète du serveur SSH.

L'accès au serveur SSH sur l'IOS de Cisco peut également être handicapé en retirant SSH comme protocole valide de transport. Ceci peut être fait en appliquant la commande entrée " transport input " le 'ssh 'étant coupé de la liste de transports autorisés sur des lignes VTY en mode configuration.

Par exemple :

line vty 0 4
transport input telnet
end

Si la fonctionnalité de serveur de SSH est désirée, l'accès au serveur peut être limité aux adresses spécifiques d'IP source ou être bloqué entièrement par l'utilisation des listes de contrôle d'accès (ACLs) sur les lignes de VTY comme montré dans le URL suivant :

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2950/1219ea1/scg/swacl.htm#xtocid14

Plus d'information pour configurer les ACLs sur le site public de Cisco :

http://www.cisco.com/warp/public/707/confaccesslists.html

Un exemple d'une accès-liste de VTY peut être trouvé ici :

access-list 2 permit 10.1.1.0 0.0.0.255
access-list 2 deny any

line vty 0 4
access-class 2 in
end

Vous pouvez également bloquer les connexions d'arrivée de SSH pour votre dispositif avec un dispositif de filtrage de paquet externe tel un firewall ou un routeur qui bloque le trafic au port 22 de TCP.