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
|
<define-tag description>Entfernte Ausnutzbarkeit</define-tag>
<define-tag moreinfo>
<p>ISS X-Force veröffentlichte eine Ankündigung über eine OpenSSH <q>Entfernte
Challenge-Verwundbarkeit</q>. Unglücklicherweise war die Ankündigung in einigen
Punkten falsch, was zu einer weitreichenden Verwirrung über den Einfluss
dieser Verwundbarkeit führte. Keine Version von OpenSSH in Debian ist von dem
SKEY und BSD_AUTH Authentifizierungsmethoden betroffen, wie sie in dem
ISS-Gutachten beschrieben werden. Jedoch beinhaltet Debian OpenSSH-Server mit
PAM-Unterstützung, die in den späteren Gutachten des OpenSSH-Teams als verwundbar
beschrieben wird. (Diese ausnutzbare Fähigkeit ist die Authentifizierung
mittels PAM über den interaktiven Tastaturmechanismus [kbdint].) Diese
Verwundbarkeit betrifft OpenSSH-Versionen 2.3.1 bis 3.3. Zurzeit ist kein
Exploit für die PAM/kbdint-Verwundbarkeit bekannt, jedoch sind die Details
öffentlich bekannt. All diese Verwundbarkeiten wurden in OpenSSH 3.4
behoben.</p>
<p>Zusätzlich zu den Sicherheitsbehebungen, die oben angeführt sind,
unterstützen unsere OpenSSH-Pakete ab Version 3.3 die neue
Privilegteilungs-Fähigkeit von Niels Provos, die ssh dahingehend ändert, einen
getrennten unprivilegierten Prozess für die meiste Arbeit zu verwenden.
Verwundbarkeiten im nicht privilegierten Account werden auf eine leere chroot
eingeschränkt, anstelle zu einer direkten root-Beeinträchtigung zu führen.
Privilegteilung sollte helfen, das Risiko durch zukünftige
OpenSSH-Beeinträchtigungen zu mildern.</p>
<p>Debian 2.2 (Potato) wurde mit einem auf OpenSSH 1.2.3 basierendem ssh-Paket
ausgeliefert, und ist von den Verwundbarkeiten in diesem Gutachten nicht
betroffen. Benutzer, die immer noch ein ssh-Paket Version 1.2.3 verwenden,
müssen nicht sofort auf OpenSSH 3.4 aktualisieren. Benutzer, die auf die
OpenSSH-Version 3.3 Pakete aktualisiert haben, die mit früheren Versionen von
DSA-134 veröffentlicht wurden, sollten auf die neuen Version 3.4
OpenSSH-Pakete aktualisieren, da die Version 3.3 Pakete verwundbar sind. Wir
empfehlen Benutzern, die OpenSSH 1.2.3 verwenden, eine Umstellung auf OpenSSH
3.4 zu erwägen, um den Vorteil der Privilegteilungs-Möglichkeit zu nutzen.
(Jedoch nochmals, uns ist keine spezielle Verwundbarkeit in OpenSSH 1.2.3
bekannt. Bitte lesen Sie sorgfältig die Vorsichtsmaßnahmen, die unterhalb
aufgeführt sind, bevor Sie von OpenSSH 1.2.3 aktualisieren.) Wir empfehlen,
dass alle Benutzer, die eine zurückportierte Version von OpenSSH Version 2.0
oder größer auf Potato verwenden, auf OpenSSH 3.4 aktualisieren.</p>
<p>Die aktuelle Pre-Release Version von Debian (Woody) beinhaltet ein OpenSSH
Version 3.0.2p1 Paket (ssh), das für das oben beschriebene PAM/kbdint-Problem
anfällig ist. Wir empfehlen den Benutzern, auf OpenSSH 3.4 zu aktualisieren
und Privilegteilung zu aktivieren. Bitte lesen Sie die Release-Bemerkungen
unterhalb sorgfältig durch, bevor Sie aktualisieren. An aktualisierten Paketen
für ssh-krb5 (ein OpenSSH-Paket, das Kerberos-Authentifizierung unterstützt)
wird im Augenblick noch gearbeitet. Benutzer, die ihre OpenSSH-Pakete zurzeit
nicht aktualisieren können, möchten eventuell um die bekannten
Verwundbarkeiten herumarbeiten, indem sie die verwundbaren Fähigkeiten
abschalten: Vergewissern Sie sich, dass die folgenden Zeilen kein
Kommentarzeichen vorangestellt haben und in Ihrer /etc/ssh/sshd_config
vorhanden sind, und starten Sie ssh neu</p>
<pre>
PAMAuthenticationViaKbdInt no
ChallengeResponseAuthentication no
</pre>
<p>Es sollte keine anderen PAMAuthenticationViaKbdInt oder
ChallengeResponseAuthentication Einträge in sshd_config vorhanden sein.</p>
<p>Das beendet den Verwundbarkeitsabschnitt dieses Gutachten. Folgend finden
Sie die Release-Bemerkungen zum OpenSSH 3.4 Paket und die
Privilegteilungs-Fähigkeiten. URLs für die OpenSSH 3.4 Pakete stehen am
Ende.</p>
<p>Einige Notizen zu möglichen Fragen, die mit dieser Aktualisierung
zusammenhängen:</p>
<ul>
<li>Dieses Paket führt einen neuen Account namens <q>sshd</q> ein, der im
Privilegteilungs-Code verwendet wird. Falls kein sshd-Account existiert, wird
das Paket versuchen, einen zu erstellen. Wenn der Account bereits
vorhanden ist, wird er wiederverwendet. Falls Sie nicht wollen, dass dies
passiert, müssen Sie dies manuell ändern.</li>
<li>(Nur für Potato relevant) Diese Aktualisierung führt eine zurückportierte
Version 0.9.6c der SSL-Bibliothek ein. Das bedeutet, dass Sie das
libssl0.9.6 Paket ebenfalls aktualisieren müssen.</li>
<li>(Nur für Potato relevant) Diese Aktualisierung verwendet standardmäßig die
Version 2 des SSH-Protokolls (selbst wenn sie dazu konfiguriert ist,
Version 1 des SSH-Protokolls zu unterstützen). Das kann vorhandene
Einrichtungen unwirksam
machen, bei denen RSA-Authentifizierung verwendet wurde. Sie müssen
entweder
<ul>
<li>-1 zum ssh-Aufruf hinzufügen, um weiterhin SSH Protokoll 1 und Ihre
vorhandenen Schlüssel zu verwenden, oder</li>
<li>die <kbd>Protocol</kbd>-Zeile in <tt>/etc/ssh/ssh_config</tt>
und/oder <tt>/etc/ssh/sshd_config</tt> auf <q><kbd>Protocol 1,2</kbd></q>
ändern, um Protokoll 1 vor Protokoll 2 zu verwenden, oder
<li>neue rsa- oder dsa-Schlüssel für SSH Protokoll 2 erstellen.</li>
</ul>
</li>
<li>sshd hat standardmäßig Privilegienteilung aktiviert, selbst wenn Sie es
nicht explizit in <tt>/etc/ssh/sshd_config</tt> aktivieren.</li>
<li>ssh unterstützt nicht länger das Zurückfallen auf rsh.</li>
<li>(Nur für Potato relevant) Privilegienteilung funktioniert im Augenblick
nicht mit Linux 2.0 Kerneln.</li>
<li>Privilegienteilung funktioniert im Augenblick mit PAM-Authentifizierung
über den KeyboardInteraktive-Mechanismus nicht.</li>
<li>Privilegienteilung verursacht, dass einige PAM-Module nicht funktionieren,
die erwarten, mit root-Privilegien zu laufen.</li>
<li>Wenn Sie Gründe haben, aus denen Sie Privilegienteilung im Augenblick
wegen den oben genannten Gründen nicht verwenden können, können Sie es
abschalten, indem Sie <q>UsePrivilegeSeparation no</q> in Ihre
/etc/ssh/sshd_config Datei einfügen.</li>
</ul>
<p>Einige Dinge von früheren OpenSSH 3.3p1 Paketen, die mit diesem Gutachten
korrigiert wurden (kein komplettes changelog):</p>
<ul>
<li>(Nur für Potato relevant) Die Installationsfrage, <q>do you want to allow
protocol 2 only</q> steht nicht länger standardmäßig auf <q>yes</q> für Potato.
Benutzer, die
diese Frage mit <q>yes</q> beantwortet haben und ebenfalls gewählt haben,
dass ihre sshd_config Datei neu generiert werden soll, haben entdeckt,
dass Sie sich nicht mehr auf ihren Server über das Protokoll 1 verbinden
konnten. Lesen Sie <tt>/usr/doc/ssh/README.Debian</tt> für eine
Anleitung, wie Sie Protokoll 1 aufdrehen können, falls Sie sich in dieser
Situation befinden. Da der Standardwert im Potato-Paket nun <q>no</q> ist,
sollte dies kein Problem für Leute sein, die in Zukunft von Version 1.2.3
aktualisieren.</li>
<li>(Nur für Potato relevant) Das ssh-Paket hat keinen Konflikt mehr mit
rsh-server, auch stellt es keine rsh-Alternative mehr zur Verfügung.</li>
<li>Die Installation bricht nicht mehr ab, wenn Benutzer Protokoll 1-Schlüssel
neu generieren wollen</li>
</ul>
<p>Wir wollen nochmals darauf hinweisen, dass wir es bedauern, weniger
getestete Pakete mit größeren Änderungen als üblicherweise verbreiten zu müssen;
wegen der potenziellen Schwere und der nicht spezifischen Natur der
ursprünglichen Bedrohung entschieden wir uns, dass unsere Benutzer am
besten so rasch wie
möglich mit Paketen zur Bewertung gedient ist. Wir werden zusätzliche
Informationen senden, wenn wir sie erhalten, und weiter an den ausstehenden
Problemen arbeiten.</p>
</define-tag>
# do not modify the following line
#include "$(ENGLISHDIR)/security/2002/dsa-134.data"
#use wml::debian::translation-check translation="6822acd35ad6eb7044786082d7d0deb96747c492"
# $Id$
|
