Je vois que tu n'a riens compris. Dans les deux cas que tu cite, le problème n'est pas une faille d'openssh.
Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.
La raison est très simple : openssh est un logiciel stratégique pour la sécurité, parce qu'il gère l'accès distant et complet au système hôte, et parce qu'il est installé sur une grande majorité de serveurs Unix (je pense que c'est le daemon le plus souvent présent sur un serveur unix, plus encore qu'apache, dovecot ou sendmail). La faille du paquet openssl de Debian affectait, en fait, beaucoup d'autres logiciels (dont OpenVPN par exemple), mais on s'est inquiété en premier lieu de ses conséquences sur openssh précisément pour ces raisons. De même, cette position « privilégiée » d'openssh explique clairement pourquoi ce logiciel a été choisi par le pirate des serveurs Red Hat : même s'il avait la possibilité de générer un binaire trafiqué puis signer n'importe quel paquet inclus dans RHEL (ce qui est probable), openssh restait en toute logique la cible de premier choix.
Les failles d'OpenSSH sont rarissimes quand on considère son exposition. Et quand elles arrivent, ce sont soit des problèmes de détail aux conséquences mineures (type vol possible d'un cookie xorg par root), soit failles très sophistiquées et complexes, mais jamais de grossières erreurs de programmation. Ce logiciel est développé par les gens d'OpenBSD, qui sont connus pour faire de leur mieux pour essayer d'éviter les problèmes de sécurité, même lorsque c'est aux dépends des fonctionnalités ou des performances. Et c'est certainement l'un des (sinon _le_) logiciels libres les plus audités : autant par les pirates (la découverte d'une faille dans ce logiciel leur assurerais une efficacité maximum), par les consultants en sécurité (une telle découverte leur garantirais une énorme promotion), par les équipes de sécurité des divers distributions et des autres unix (y compris Mac OS, AIX, Cisco, Juniper & co, qui incluent aussi ce logiciel), par les agences gouvernementales type NSA, il fait partis des programmes audités en boucle par coverty, ... C'est aussi un des premiers logiciels a avoir été mis sous la protection/surveillance de SELinux et d'AppArmor (et dans une moindre mesure, de systrace - et il est généralement compilé avec propolice/-fstack-protector), et un de ceux pour lesquels ces outils sont activés par défaut sur plusieurs distributions : un comportement "bizarre" (ie. dû à une faille encore non révélée en cours d'exploitation) dans ce logiciel se remarquerai très vite.
À mon sens, l'utilisation de serveurs ssh alternatif est moins un gain de sécurité par la diversité qu'un risque dû au manque d'audit intensif de ces derniers (autrement dit, une tentative de sécurité par l'obscurité).
Plus sérieusement, si vous vous inquiétez d'utiliser des logiciels dont le code est fagile et très régulièrement affecté par des problèmes de sécurité, regardez plutôt du coté de l'historique sécu de PHPMyAdmin ou Clamav (ps: et bravo aux distributions responsables qui ont choisi de ne _pas_ inclure cette passoire de phpmyadmin). Je crois qu'il ne se passe pas un mois sans que je soit obligé d'upgrader ces logiciels dans l'urgence sur certains serveurs...
[^] # Re: deux fois ...
Posté par herodiade . En réponse au journal Intrusion sur les serveurs Fedora/Red Hat. Évalué à 10.
Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.
La raison est très simple : openssh est un logiciel stratégique pour la sécurité, parce qu'il gère l'accès distant et complet au système hôte, et parce qu'il est installé sur une grande majorité de serveurs Unix (je pense que c'est le daemon le plus souvent présent sur un serveur unix, plus encore qu'apache, dovecot ou sendmail). La faille du paquet openssl de Debian affectait, en fait, beaucoup d'autres logiciels (dont OpenVPN par exemple), mais on s'est inquiété en premier lieu de ses conséquences sur openssh précisément pour ces raisons. De même, cette position « privilégiée » d'openssh explique clairement pourquoi ce logiciel a été choisi par le pirate des serveurs Red Hat : même s'il avait la possibilité de générer un binaire trafiqué puis signer n'importe quel paquet inclus dans RHEL (ce qui est probable), openssh restait en toute logique la cible de premier choix.
Les failles d'OpenSSH sont rarissimes quand on considère son exposition. Et quand elles arrivent, ce sont soit des problèmes de détail aux conséquences mineures (type vol possible d'un cookie xorg par root), soit failles très sophistiquées et complexes, mais jamais de grossières erreurs de programmation. Ce logiciel est développé par les gens d'OpenBSD, qui sont connus pour faire de leur mieux pour essayer d'éviter les problèmes de sécurité, même lorsque c'est aux dépends des fonctionnalités ou des performances. Et c'est certainement l'un des (sinon _le_) logiciels libres les plus audités : autant par les pirates (la découverte d'une faille dans ce logiciel leur assurerais une efficacité maximum), par les consultants en sécurité (une telle découverte leur garantirais une énorme promotion), par les équipes de sécurité des divers distributions et des autres unix (y compris Mac OS, AIX, Cisco, Juniper & co, qui incluent aussi ce logiciel), par les agences gouvernementales type NSA, il fait partis des programmes audités en boucle par coverty, ... C'est aussi un des premiers logiciels a avoir été mis sous la protection/surveillance de SELinux et d'AppArmor (et dans une moindre mesure, de systrace - et il est généralement compilé avec propolice/-fstack-protector), et un de ceux pour lesquels ces outils sont activés par défaut sur plusieurs distributions : un comportement "bizarre" (ie. dû à une faille encore non révélée en cours d'exploitation) dans ce logiciel se remarquerai très vite.
À mon sens, l'utilisation de serveurs ssh alternatif est moins un gain de sécurité par la diversité qu'un risque dû au manque d'audit intensif de ces derniers (autrement dit, une tentative de sécurité par l'obscurité).
Plus sérieusement, si vous vous inquiétez d'utiliser des logiciels dont le code est fagile et très régulièrement affecté par des problèmes de sécurité, regardez plutôt du coté de l'historique sécu de PHPMyAdmin ou Clamav (ps: et bravo aux distributions responsables qui ont choisi de ne _pas_ inclure cette passoire de phpmyadmin). Je crois qu'il ne se passe pas un mois sans que je soit obligé d'upgrader ces logiciels dans l'urgence sur certains serveurs...