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
156
157
158
159
160
161
162
163
164
165
166
167
|
#use wml::debian::translation-check translation="6822acd35ad6eb7044786082d7d0deb96747c492" mindelta="1"
<define-tag description>fjärrattack</define-tag>
<define-tag moreinfo>
<p>
ISS X-Force släppte en bulletin om ”fjärranropssårbarhet” i
OpenSSH:
Tyvärr var bulletinen felaktig på några punkter, vilket ledde till utbredd
förvirring om hur allvarlig denna sårbarhet var.
Ingen version av OpenSSH på Debian påverkas av SKEY- och
BSD_AUTH-autentiseringsmetoderna som beskrivs i ISS-bulletinen.
Debian innehåller dock OpenSSH-servrar med den PAM-funktion som beskrivs i
en senare bulletin från OpenSSH-gruppen.
(Denna sårbarhet är autentisering med PAM via en tangentbordsinteraktiv
mekanism [kbdint].)
Denna sårbarhet påverkar OpenSSH version 2.3.1 till 3.3.
Inget sätt att utnyttja PAM-/kbdint-sårbarheten är för närvarande känd, men
detaljerna är allmänt kända.
Alla dessa sårbarheter rättades i OpenSSH 3.4.
</p>
<p>
Förutom de rättade sårbarheter som beskrivs ovan innehåller våra
OpenSSH-paket version 3.3 eller högre den nya privilegiedelningsfunktionen
av Niels Provos, vilken ändrar ssh så att det
använder en icke-privilegierad process för att hantera det mesta.
Sårbarheter i den icke-privilegierade delen av OpenSSH leder till att ett
icke-privilegierat konto som
är begränsat till en tom chroot komprometteras, istället för en direkt
root-kompromettering.
Privilegiedelningen mildrar risken hos framtida OpenSSH-komprometteringar.
</p>
<p>
Med Debian 2.2 (potato) kom ett ssh-paket baserat på OpenSSH 1.2.3, och är
inte sårbart för de sårbarheter som beskrivits i denna bulletin.
Användare som fortfarande kör ett ssh-paket av version 1.2.3 behöver inte
omedelbart uppgradera till OpenSSH 3.4.
Användare som uppgraderade till de OpenSSH version 3.3-paket som släpptes
med tidigare versioner av DSA-134 bör uppgradera till de nya OpenSSH version
3.4-paketen, då version 3.3-paketen är sårbara.
Vi föreslår att användare som kör OpenSSH 1.2.3 bör överväga att byta till
OpenSSH 3.4 för att dra nytta av privilegiedelningsfunktionen.
(Dock skall vi återigen nämna att vi inte känner till någon sårbarhet i
OpenSSH 1.2.3.
Läs noggrant genom varningarna nedan innan ni uppgraderar från OpenSSH
1.2.3.)
Vi rekommenderar att alla som kör en bakåtanpassad version av OpenSSH 2.0
eller högre på potato uppgraderar till OpenSSH 3.4.
</p>
<p>
Den aktuella uttestningsutgåvan av Debian (woody) innehåller ett paket med
OpenSSH version 3.0.2p1 (ssh), vilket är sårbart för PAM-/kbdint-problemet
som beskrivs ovan.
Vi rekommenderar att användare uppgraderar till OpenSSH 3.4 och aktiverar
privilegiedelning.
Läs noggrant genom varningarna nedan innan ni uppgraderar.
Uppdaterade paket för ssh-krb5 (ett OpenSSH-paket som stöder autentisering
via kerberos) är för närvarande under utveckling.
Användare som inte kan uppgradera sina OpenSSH-paket kan gå runt de kända
sårbarheterna genom att slå av de sårbara funktionerna:
se till att följande rader finns och inte är utkommenterade i
/etc/ssh/sshd_config och starta om ssh:
</p>
<pre>
PAMAuthenticationViaKbdInt no
ChallengeResponseAuthentication no
</pre>
<p>
Det bör inte finnas några fler PAMAuthenticationViaKbdInt eller
ChallengeResponseAuthentication i sshd_config.
</p>
<p>
Härmed slutar den del av bulletinen som hanterar sårbarheten.
Det som följer är versionsfakta gällande OpenSSH 3.4-paketet och
privilegiedelningsfunktionen.
URLer för OpenSSH 3.4-paketen finns nederst.
</p>
<p>Information om möjliga problem med denna uppgradering:</p>
<ul>
<li>Paketet introducerar ett nytt konto vid namn ”sshd” som
används av privilegiedelningskoden.
Om det inte finns något sshd-konto kommer paketet försöka skapa ett.
Om kontot redan finns kommer det att återanvändas.
Om du inte vill att detta skall ske måste du ändra det manuellt.</li>
<li>(gäller endast potato) Denna uppdatering lägger till en bakåtanpassad
version 0.9.6c av SSL-biblioteket. Detta betyder att du även måste
uppgradera ssl-paketet.</li>
<li>(gäller endast potato) Denna uppdatering använder som standard version
2 av SSH-protokollet, något som kan förstöra för existerande system där
RSA-autentisering används.
Du måste antingen
<ul>
<li>lägga till -1 till ssh:s kommandorad för att fortsätta använda
SSH-protokoll 1 och dina existerande nycklar, eller</li>
<li>ändra <kbd>Protocol</kbd>-raden i <tt>/etc/ssh/ssh_config</tt> och/eller
<tt>/etc/ssh/sshd_config</tt> till ”<kbd>Protocol 1,2</kbd>”
för att försöka med protokoll 1 före protokoll 2, eller
<li>skapa nya rsa- eller dsa-nycklar för SSH-protokoll 2.</li>
</ul>
</li>
<li>sshd använder privilegiedelning som standard, även om du inte explicit
aktiverar det i <tt>/etc/ssh/sshd_config</tt>.
<li>Funktionen att falla tillbaka från ssh till rsh är inte längre
tillgänglig.</li>
<li>(gäller endast potato) Privilegiedelning fungerar för närvarande inte
för Linux 2.0-kärnor.</li>
<li>Privilegiedelning fungerar för närvarande inte med PAM-autentisering
via KeyboardInteractive-mekanismen.</li>
<li>Privilegiedelning gör att vissa PAM-moduler som förväntar sig att köras
som root slutar fungera.</li>
<li>Om du av någon anledning inte kan använda privilegiedelning på grund
av något av problemen som beskrivs ovan kan du återgå till tidigare
beteende genom att lägga
in ”<kbd>UsePrivilegeSeparation no</kbd>” i din
<tt>/etc/ssh/sshd_config</tt>-fil.
</ul>
<p>Några problem med tidigare openssh 3.3p1-paket som rättats i denna
bulletin (inte en komplett ändringslogg):</p>
<ul>
<li>(gäller endast potato) installationsfrågan, ”vill du endast
tillåta protokoll 2” har inte längre ”ja” som
förval för potato-paketen.
Användare som svarade ja på denna fråga och även valde att skapa
en ny sshd_config-fil upptäckte att de inte längre kunde ansluta
mot sina servrar via protokoll 1.
Se <tt>/usr/doc/ssh/README.Debian</tt>
för instruktioner om hur man aktiverar protokoll 1 om du hamnat i
denna situation.
Eftersom förvalet i potatopaketen nu är ”nej” bör detta
inte vara ett problem som i framtiden uppgraderar från version
1.2.3.</li>
<li>(gäller endast potato) ssh-paketet har ej längre en konflikt mot
rsh-server, och tillhandahåller inte heller ett rsh-alternativ.</li>
<li>installationen misslyckas inte längre om användaren väljer att
generera protokoll 1-nycklar.</li>
</ul>
<p>Återigen ber vi om ursäkt för att vi måste släppa paket med större
ändringar och mindre testning än vad vi normalt gör; givet den möjliga
allvarlighetsgraden och icke-specifika natur hos det ursprungliga
hotet valde vi att våra
användare bäst betjänades genom att ha paket tillgängliga för utvärdering så
fort som möjligt.
Vi kommer sända ut ytterligare information när den når oss, och kommer
fortsätta arbeta på de kvarvarande problemen.</p>
</define-tag>
# do not modify the following line
#include "$(ENGLISHDIR)/security/2002/dsa-134.data"
|
