[DDR] webwml://security/2002/dsa-134.wml
Bonjour à tous,
voici la derniere mise à jour de la dsa-134 (sur ssh)
merci par avance pour les relectures,
a+
--
Pierre Machard
<pmachard@tuxfamily.org> TuxFamily.org
<pmachard@techmag.net> techmag.net
+33 6 681 783 65 http://migus.tuxfamily.org/gpg.txt
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
#use wml::debian::translation-check translation="1.11" maintainer="Pierre Machard"
<define-tag description>Exploitation à distance</define-tag>
<define-tag moreinfo>
<p>ISS X-Force a publié une annonce au sujet d'une faille du système
d'identification à distance (<i>Remote Challenge Vulnerability</i>).
Malheureusement, l'annonce était fausse sur certains points, ce qui a
conduit à la confusion la plus complète. Aucune des versions d'OpenSSH
contenue dans Debian n'est touchée par les méthodes d'authentification
SKEY et BSD_AUTH décrites dans l'annonce d'ISS. De plus, Debian n'intègre
pas de serveurs OpenSSH avec la fonction PAM telle qu'elle est décrite
dans le dernier bulletin de l'équipe OpenSSH. (Cette fonction vulnérable
est la fonction d'authentification qui utilise PAM via le mécanisme
interactif au clavier [kbdinit].) Cette vulnérabilité touche les
versions d'OpenSSH de la 2.3.1 à la 3.3. Aucune exploitation n'a encore
était faite à ce jour de la vulnérabilité de PAM/kbdinit, mais les détails
sont connus sur la place publique. Toutes ces vulnérabilités ont été corrigées
dans OpenSSH 3.4.</p>
<p>En plus des rustines à ces vulnérabilités, nos paquets OpenSSH
versions 3.3 et supérieures utilisent la fonction de séparation des
droits de Niels Provos, qui emploie un processus non-privilégié pour traiter
le travail courant. Des failles dans les parties non-privilégiées
d'OpenSSH compromettraient un compte non-privilégié restreint à un chroot
vide, au lieu d'une compromission directe du compte root. La séparation
des droits (<i>Privilege separation</i>) devrait permettre d'éviter
les risques d'un future compromission d'OpenSSH.</p>
<p>Debian 2.2 (<i>Potato</i>) est équipée d'un paquet ssh basé sur
OpenSSH 1.2.3, qui n'est pas sensible à la faille dont il est
question dans ce bulletin. Les utilisateurs qui utilisent toujours une
version 1.2.3 du paquet ssh n'ont pas immédiatement besoin de
passer à la version 3.4 d'OpenSSH. Les utilisateurs qui sont déjà
passés à la version 3.3 d'OpenSSH dans les versions ultérieures
de la DSA-134 doivent mettre à jour leurs paquets et passer à la version
3.4 d'OpenSSH, étant donné que les paquets 3.3 sont vulnérables. Nous
suggérons aux personnes qui utilisent OpenSSH 1.2.3 de passer à la
version 3.4 pour profiter de la fonction de séparation des droits.
(Même si encore une fois nous n'avons pas d'informations sur l'existence
d'une faille de sécurité dans OpenSSH 1.2.3. Veuillez lire
attentivement la mise en garde ci-dessous avant de mettre à jour
OpenSSH 1.2.3). Nous recommandons aux personnes utilisant
des versions rétro-portées d'OpenSSH version 2.0 ou supérieures
sur <i>Potato</i> de passer à OpenSSH 3.4.</p>
<p>L'actuelle pré-publication de Debian (<i>Woody</i>) contient un
paquet OpenSSH version 3.0.2p1 (ssh), qui est vulnérable au problème
de PAM/kbdinit décrit ci-dessus. Nous recommandons aux utilisateurs de
passer à OpenSSH 3.4 et d'activer la séparation des droits.
Des paquets ssh-krb5 à jour (un paquet OpenSSH supportant l'authentification
par la méthode kerberos) sont actuellement en cours de préparation.
Les utilisateurs qui ne peuvent pas mettre à jour leurs paquets OpenSSH
peuvent contourner la faille de sécurité en désactivant la fonction
défaillante : assurez vous que les lignes suivantes soient bien
présentes dans votre fichier /etc/ssh/sshd_config et qu'elles sont
décommentées puis relancez ssh</p>
<pre>
PAMAuthenticationViaKbdInt no
ChallengeResponseAuthentication no
</pre>
<p>Il ne devrait pas y avoir d'autre entrée PAMAuthentificationViaKbdInt
ou ChallengeResponseAuthentication dans sshd_config.</p>
<p>Ceci conclut la section vulnérabilité de ce bulletin. La suite
contient les notes de publication du paquet OpenSSH 3.4 et
la fonction de séparation des droits. Les URLs pour les paquets
OpenSSH 3.4 se trouvent en bas de la page.</p>
<p>Quelques détails sur les conséquences possibles de cette mise
à jour :</p>
<ul>
<li>Ce paquet installe un nouveau compte appelé « sshd » qui
est employé dans le code de séparation des droits. Si aucun compte
sshd n'existe, le paquet essayera d'en créer un. Si un compte existe
déjà, il sera ré-employé. Si vous ne souhaitez pas que cela arrive,
vous devrez le corriger à la main.</li>
<li>(Valable uniquement pour <i>Potato</i>) Cette mise à jour ajoute
un rétro-portage de la version 0.9.6c de la bibliothèque SSL. Ce
qui signifie que vous devrez également mettre à jour le paquet
libssl0.9.6.</li>
<li>(Valable uniquement pour <i>Potato</i>) Cette mise à jour utilise
par défaut la version 2 du protocole SSH (même s'il est configuré
pour supporter la version 1 du protocole SSH). Ceci peut casser
les configurations existantes qui utilisent l'authentification RSA.
Vous devrez soit :
<ul>
<li>ajouter -1 à l'invocation de la commande ssh pour continuer à
utiliser la version 1 du protocole SSH et votre clé actuelle,
ou
<li>modifier la ligne <kbd>Protocol</kbd> dans le fichier
<tt>/etc/ssh/ssh_config</tt>
et/ou
<tt>/etc/ssh/sshd_config</tt> pour "<kbd>Protocol 1,2</kbd>"
pour essayer d'utiliser la version 1 du protocole avant d'essayer
la version 2,
ou
<li>créer de nouvelles clés rsa ou dsa pour SSH protocole 2
</ul>
</li>
<li>sshd active par défaut la séparation des droits, même si vous
ne l'activer pas de façon explicite dans le fichier
<tt>/etc/ssh/sshd_config</tt>.</li>
<li>le recours à rsh n'est plus possible.</li>
<li>(Valable uniquement pour <i>Potato</i>) La séparation des droits
ne fonctionne pas encore avec les noyaux Linux 2.0.</li>
<li>La séparation des droits ne fonctionne pas encore avec
l'authentification PAM employant le mécanisme de clavier interactif
(<i>KeyboardInteractive mechanism</i>).</li>
<li>La séparation des droits empêche le fonctionnement de certains
modules PAM qui sont censés fonctionner avec les privilèges du root.</li>
<li>Si à cause d'une des raisons évoquée ci-dessus, vous ne pouvez pas dans
l'immédiat utiliser la séparation des droits vous pouvez la désactiver en
ajoutant
« <kbd>UsePrivilegeSeparation no</kbd> » dans votre fichier
<tt>/etc/ssh/sshd_config</tt>.</li>
</ul>
<p>Voici quelques éléments des paquets OpenSSH 3.3p1 qui ont été corrigés
dans ce bulletin (Changelog Partiel) :</p>
<ul>
<li>(Valable uniquement pour <i>Potato</i>) La réponse à la question
d'installation « Souhaitez vous utiliser la version 2 du
protocole par défaut, n'est plus « Oui » par défaut pour
les paquets <i>Potato</i>. Les utilisateurs qui répondraient
« Oui » à cette question et choisiraient également de
regénérer leur fichier sshd_config constateront qu'ils ne peuvent
désormais plus se connecter à leur serveur grâce au protocole 1.
Regardez <tt>/usr/doc/ssh/README.Debian<tt> pour des instructions sur la
façon d'activer le protocole 1, si vous vous trouvez dans cette
situation. Étant donné que la réponse par défaut est « Non »,
cela ne devrait plus poser problème pour les futures mises à jour à la
version 1.2.3.</li>
<li>(Valable uniquement pour <i>Potato</i>) le paquet ssh n'entre plus en
conflit avec rsh-server, et ne fournit plus d'alternatives à rsh.</li>
<li>L'installation n'échoue plus si les utilisateurs choisissent de
générer des clés pour la version 1 du protocole.<li>
</ul>
<p>Encore une fois, ne regrettons d'avoir publié des paquets avec des
changements profonds, en les testant moins bien qu'à notre habitude ;
en donnant la sévérité probable et la nature non-spécifique de la menace
d'origine, nous avons décidé que le meilleur moyen de servir nos
utilisateurs était de mettre à disposition des paquets aussi rapidement
que possible. Nous vous fournirons des informations complémentaires dès
que nous en aurons, et nous continuerons à travailler sur les problèmes
auxquels vous êtes confrontés.</p>
</define-tag>
# do not modify the following line
#include "$(ENGLISHDIR)/security/2002/dsa-134.data"
Reply to: