1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
#use wml::debian::translation-check translation="6822acd35ad6eb7044786082d7d0deb96747c492"
<define-tag description>explotación remota</define-tag>
<define-tag moreinfo>
<p>La ISS X-Force publicó un aviso sobre una «Vulnerabilidad Remota en el
"Challenge"» en OpenSSH. Desafortunadamente, el aviso era incorrecto en
algunos puntos, lo que condujo a una confusión generalizada sobre el
impacto de esta vulnerabilidad. Ninguna versión de OpenSSH en Debian se ve
afectada por los métodos de autentificación SKEY y BSD_AUTH descritos en
el aviso de ISS. Sin embargo, Debian incluye servidores OpenSSH con la
característica PAM descrita como vulnerable en el aviso posterior enviado
por el equipo de OpenSSH. (Esta característica vulnerable se refiere a la
autentificación mediante PAM usando el mecanismo de teclado interactivo
[kbdint]). Esta vulnerabilidad afecta a las versiones OpenSSH 2.3.1 a 3.3.
No se conoce aún nada que explote la vulnerabilidad de PAM/kbdint, pero
los detalles ya son de dominio público. Todas estas vulnerabilidades están
resueltas en OpenSSH 3.4.</p>
<p>Además de las correcciones a las vulnerabilidades descritas
anteriormente, nuestros paquetes de OpenSSH versión 3.3 y superiores
incluyen la nueva característica de separación de privilegios de Niels
Provos, que modifica ssh para que use un proceso aparte, sin privilegios,
para realizar la mayoría del trabajo. Las vulnerabilidades en las partes
sin privilegios de OpenSSH supondrán un compromiso en una cuenta sin
privilegios restringida a un entorno chroot vacío, en lugar de un
compromiso directo sobre root. La separación de privilegios debería
ayudar a mitigar los riesgos de cualquier compromiso futuro en OpenSSH.</p>
<p>Debian 2.2 (potato) salió con un paquete ssh basado en OpenSSH 1.2.3, y
no es vulnerable a los fallos descritos en este aviso. Los usuarios que
aún tengan funcionando un paquete ssh versión 1.2.3 no necesitan actualizar
de forma inmediata a OpenSSH 3.4. Los usuarios que ya actualizaron los
paquetes de OpenSSH a la versión 3.3 publicadas junto a las anteriores
iteraciones del DSA-134 deberían actualizar a la nueva versión 3.4 de los
paquetes de OpenSSH, ya que la versión 3.3 era vulnerable. Sugerimos a los
usuarios que estén ejecutando OpenSSH 1.2.3 que consideren migrar a
OpenSSH 3.4 para aprovechar la ventaja que supone la característica de
separación de privilegios. (Sin embargo, repetimos, no tenemos constancia
específica de ninguna vulnerabilidad en OpenSSH 1.2.3. Por favor, lea
cuidadosamente las notas de publicación antes de actualizar). Recomendamos
que cualquier usuario que esté ejecutando una versión 2.0 o superior de
OpenSSH en potato, pase a OpenSSH 3.4.</p>
<p>La versión actual de Debian en pre-publicación (woody) incluye un
paquete OpenSSH versión 3.0.2p1 (ssh), que es vulnerable al problema de
PAM/kbdint descrito anteriormente. Recomendamos a los usuarios que
actualicen a OpenSSH 3.4 y habiliten la separación de privilegios. Por
favor, lea actualmente las notas de publicación antes de actualizar. Se
está trabajando en paquetes actualizados de ssh-krb5 (un paquete de
OpenSSH que incluye autentificación mediante kerberos). Los usuarios que
no puedan actualizar sus paquetes de OpenSSH en este momento, pueden
evitar las vulnerabilidades conocidas descativando las características
vulnerables: asegúrse de que las siguientes líneas se encuentran en
/etc/ssh/sshd_config, sin comentar, y reinicie ssh</p>
<pre>
PAMAuthenticationViaKbdInt no
ChallengeResponseAuthentication no
</pre>
<p>No debería haber otras entradas referentes a
PAMAuthenticationViaKbdInt o ChallengeResponseAuthentication
en sshd_config.</p>
<p>Esto concluye la sección de vulnerabilidades en este aviso. Lo que
sigue son las notas de publicación relacionadas con el paquete OpenSSH
3.4 y la característa de separación de privilegios. Las URL hacia los
pquetes de OpenSSH 3.4 se encuentran al final de la página.</p>
<p>Algunas notas sobre posibles cuestiones relativas a esta
actualización:</p>
<ul>
<li>Este paquete introduce una nueva cuenta llamada `sshd' que se usa en
el código de separación de privilegios. Si no existe una cuenta sshd,
el paquete intentará crearla. Si la cuenta existe, será reutilizada.
Si no quiere que esto suceda, tendrá que corregirlo de forma manual.
<li>(relevante sólo para potato) Esta actualización incluye una adaptación
retroactiva de la biblioteca SSL 0.9.6c. Esto significa que tendrá que
actualizar también el paquete libssl0.9.6.
<li>(relevante sólo para potato) Esta actualización usa de forma
predeterminada la versión 2 del protocolo SSH (incluso si el demonio
está configurado para usar la versión 1). Esto puede hacer que
dejen de funcionar las configuraciones que usen la autentificación
RSA. Puede resolverlo de varias formas:
<ul>
<li>añada -1 a la invocación de ssh para seguir usando el protocolo
1 de SSH y las claves de que ya dispone, o
<li>cambiar la línea <kbd>Protocol</kbd> en
<tt>/etc/ssh/ssh_config</tt>
o
<tt>/etc/ssh/sshd_config</tt> a "<kbd>Protocol 1,2</kbd>"
para intentar usar el protocolo 1 antes del protocolo 2, o
<li>crear nuevas claves rsa y dsa para el protocolo 2 de SSH
</ul>
</li>
<li>sshd activa de forma predeterminada la separación de privilegios,
aunque no lo active explícitamente en
<tt>/etc/ssh/sshd_config</tt>.</li>
<li>Ya no está disponible la opción de ssh para trabajar como rsh como
comportamiento de respaldo.</li>
<li>(relevante sólo para potato) La separación de privilegios no funciona
actualmente en los núcleos Linux 2.2.</li>
<li>La separación de privilegios no funciona actualmente en conjunto con
la autentificación PAM mediante el mecanismo KeyboardInteractive.</li>
<li>La separación de privilegios provoca fallos en algunos módulos PAM que
esperan encontrarse con privilegios de root.</li>
<li>Si por algunar razón no pudiera usar la separación de privilegios en
este momento debido a alguno de los problemas descritos anteriormente,
puede desactivarla añadiendo "<kbd>UsePrivilegeSeparation no</kbd>" al
fichero <tt>/etc/ssh/sshd_config</tt>.</li>
</ul>
<p>Problemas de los paquetes de OpenSSH 3.3p1 previos corregidos en este
aviso (no es un registro de cambios completo):</p>
<ul>
<li>(relevante sólo para potato) la pregunta «do you want to allow
protocol 2 only» durante la instalación ya no es "yes" por defecto en
los paquetes de potato.
Los usuarios que contestaron "yes" a esta pretunga y escogieron
regenerar su fichero sshd_config econtrarán que yua no pueden conectar
al servidor mediante el protocolo 1. Lea
<tt>/usr/doc/ssh/README.Debian</tt> si desea instrucciones para
habilitar el protocolo 1 si se ve en esa situación. Debido a que la
opción predeterminada para Potato es "no" ahora, no debería ser motivo
de problemas para la gente que actualice en el futuro partiendo de la
versión 1.2.3.</li>
<li>(relevante sólo para potato) el paquete ssh ya no tiene conflictos
rsh-server, ni proporciona una alternativa a rsh</li>
<li>la instalación ya no falla si los usuarios escogen generar claves para
el protocolo 1.
</ul>
<p>De nuevo, lamentamos haber tenido que distribuir paquetes con grandes
cambios y menos comprobaciones que las que hacemos habitualmente. Dado el
peligro potencial y la naturaleza no específica de la amenaza original,
decidimos que nuestros usuarios estarían mejor protegidos teniendo
disponibles los paquetes para su evaluación lo más pronto posible.
Enviaremos información adicional en cuanto la tengamos, y continuaremos
trabajando en los problemas pendientes.</p>
</define-tag>
# do not modify the following line
#include "$(ENGLISHDIR)/security/2002/dsa-134.data"
|
