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
|
<define-tag description>fjernudnyttelse</define-tag>
<define-tag moreinfo>
<p>ISS X-Force udsendte en bulletin om en "Remote Challenge"-sårbarhed i
OpenSSH. Desværre var bulletinen forkert på nogle områder, hvilket medførte
udbredt forvirring om hvor alvorlig denne sårbarhed var. Ingen version af
OpenSSH i Debian er påvirket godkendelsesmetoderne SKEY og BSD_AUTH som
beskrevet i ISS-bulletinen. Men Debians distributioner indeholder
OpenSSH-servere hvor PAM-funktionen beskrevet som sårbar i den senere bullutin
som OpenSSH-teamet udsendte. (Den sårbar funktion er godkendelse ved hjælp af
PAM via en tastaturinteraktiv mekanisme [kbdint].) Sårbarheden påvirker
OpenSSH versionerne 2.3.1 til 3.3. Der er pt. ingen kendt udnyttelse af
PAM/kbdint-sårbarheden, men oplysningerne om den er offentligt kendt. Alle
disse sårbarheder er rettet i OpenSSH 3.4.</p>
<p>Ud over de rettede sårbarheder nævnt ovenfor, understøtter vore
OpenSSH-pakker fra version 3.3 og højere den nye rettighedsseparationsfunktion
(privilege separation) fra Niels Provos, som ændrer SSH til at bruge en
separat upriviligeret proces til at håndtere det meste af arbejdet.
Sårbarheder i de upriviligerede dele af OpenSSH vil føre til kompromittering af
en upriviligeret konto som er begrænset til en tom chroot, fremfor en direkte
root-udnyttelse. Rettighedsseparation skulle hjælpe med at minimere risikoen
for evt. fremtidige kompromitteringer af OpenSSH.</p>
<p>Debian 2.2 (potato) blev udgivet med en ssh-pakke baseret på OpenSSH 1.2.3,
og er ikke sårbar overfor sårbarhederne beskrevet i denne bulletin. Brugere
som stadig kører med version 1.2.3 af ssh-pakken behøver ikke, omgående at
opgradere til OpenSSH 3.4. Brugere som opgraderede til OpenSSH 3.3-pakkerne
der blev udgivet i forbindelse med tidligere udgaver af DSA-134, bør opgradere
til de nye version 3.4 af OpenSSH-pakkerne, da version 3.3-pakkerne er sårbare.
Vi foreslår at brugere som kører med OpenSSH 1.2.3 overvejer at skifte til
OpenSSH 3.4, for at drage nytte af rettighedsseparationsfunktionen. (Dog skal
vi igen nævne at vi ikke har kendskab til nogen sårbarheder i OpenSSH 1.2.3.
Læs venligst advarslerne herunder grundigt før du opgraderer fra OpenSSH
1.2.3.). Vi anbefaler at alle brugere som kører med en tilbageført version af
OpenSSH version 2.0 eller højere på potato skifter til OpenSSH 3.4.</p>
<p>Den aktuelle prøveudgave af Debian Debian (woody) indeholder OpenSSH
3.0.2p1-pakken (ssh) som er særbar overfor PAM/kbdint-problemet beskrevet
ovenfor. Vi anbefaler at brugerne opgraderer til OpenSSH 3.4 og slår
rettighedsseparation til. Læs venligst udgivelsesbemærkningerne nedenfor
omhyggeligt, før du opgraderer. Opdaterede pakker af ssh-krb5 (en
OpenSSH-pakke som understøtter kerberos-godkendelse) er pt. under udvikling.
Brugere som ikke kan opgradere deres OpenSSH-pakker kan omgå de kendte
sårbarheder ved at slå de sårbare funktioner fra: sørg for at de følgende
linier er ukommenterede og tilstede i /etc/ssh/sshd_config og genstart ssh</p>
<pre>
PAMAuthenticationViaKbdInt no
ChallengeResponseAuthentication no
</pre>
<p>Der bør ikke være andre PAMAuthenticationViaKbdInt- eller
ChallengeResponseAuthentication-linier i sshd_config.</p>
<p>Hermed slutter særbarhedsafsnittet i denne bulletin. Herunder er
udgivelsesbemærkninger vedrørende OpenSSH 3.4-pakken og
rettighedsseparationsfunktionen. URL'er til OpenSSH 3.4-pakkerne finder du
nederst.</p>
<p>Nogle bemærkninger om mulige problemer i forbindelse med denne
opgradering:</p>
<ul>
<li>Pakken introducerer en ny konto kaldet "sshd" som anvendes i koden til
rettighedsseparationen. Hvis der ikke findes en sshd-konto, vil pakken
forsøge at oprette en. Hvis kontoen allerede findes, vil den blive
genbrugt. Hvis du ikke ønsker dette, er du nødt til manuelt at klare
dette.</li>
<li>(kun relevant vedrørende potato) Denne opdatering tilføjer en
tilbageførelse af SSL-bibliotekets version 0.9.6c. Dette betyder at du
også skal opgradere libssl0.9.6-pakken.</li>
<li>(kun relevant vedrørende potato) Denne opdatering bruger SSH-protokollen
i version 2 som standard (også hvis den er sat op til at understøtte
SSH-protokollens version 1). Dette kan betyde at eksisternde opsætninger
holder op med at virke, hvis RSA-adgangskontrol anvendes. Du skal enten:
<ul>
<li>tilføje -1 til ssh-kaldet for at fortsætte med at bruge
SSH-protokol 1 og dine eksisterende nøgler, eller</li>
<li>ændre <kbd>Protocol</kbd>-linien i <tt>/etc/ssh/ssh_config</tt> og/eller
<tt>/etc/ssh/sshd_config</tt> til "<kbd>Protocol 1,2</kbd>" for at prøve
protokol 1 før 2, eller</li>
<li>oprette nye RSA- eller DSA-nøgler til SSH-protokol 2</li>
</ul></li>
<li>Som standard er rettighedsseparation slået til, også selvom du ikke
eksplicit slår det til i <tt>/etc/ssh/sshd_config</tt>.</li>
<li>falden tilbage fra ssh til rsh er ikke længere tilgængelig.</li>
<li>(kun relevant vedrørende potato) Rettighedsseparation fungerer ikke pt.
sammen med Linux 2.0-kerner.</li>
<li>Rettighedsseparation virker ikke pt. med PAM-godkendelse via den
tastaturinteraktive mekanisme.</li>
<li>Rettighedsseparation får nogle PAM-moduler som forventer at køre som root,
til at holde op med at virke.</li>
<li>Hvis du af en eller anden grund ikke kan anvende rettighedsseparation for
øjeblikket på grund af et af problemerne beskrevet ovenfor, kan du slå det
fra ved at tilføje "<kbd>UsePrivilegeSeparation no</kbd>" til din
<tt>/etc/ssh/sshd_config</tt>-fil.
</ul>
<p>Nogle problemer fra tidligere OpenSSH 3.3p1-pakker, som er rettet ved
udsendelsen af denne bulletin (ikke en fuldstændig ændringslog):</p>
<ul>
<li>(kun relevant vedrørende potato) standardsvaret til
installationsspørgsmålet, "do you want to allow protocol 2 only" ("ønsker
du kun at tillade protokol 2"), er ikke længere "yes" i potato-pakker.
Bruger som svarede ja til dette spørgsmål og også valgte at genopbygge
deres sshd_config-fil, har opdaget at de ikke længere kunne få forbindelse
til deres server via protokol 1. Se <tt>/usr/doc/ssh/README.Debian</tt> for
en vejledning i hvordan man slår protokol 1 til, hvis man er havnet i denne
situation. Da standard i potato-pakkerne nu er "no", skulle det ikke være
et problem for folk som opgraderer fra version 1.2.3 i fremtiden.</li>
<li>(kun relevant vedrørende potato) ssh-package er ikke længere i konflikt med
rsh-server, og den er heller ikke et alternativ til rsh</li>
<li>installationen vil ikke længere mislykkes, hvis brugerne vælger at generere
nøgler til protokol 1.</li>
</ul>
<p>Vi beklager igen at det mod sædvane har været nødvendigt at udgive pakker
med større ændringer og mindre aftestning; men den potentielle risiko og det
ikke nærmere beskrevne oprindelige problem taget i betragtning, besluttede vi
at vore brugere ville være bedst tjent med så hurtigt som muligt at få adgang
til pakkerne. Vi vil udsende flere oplysninger så snart vi modtager dem, og vi
vil fortsat arbejde på at løse de tilbageværende problemer.</p>
</define-tag>
# do not modify the following line
#include "$(ENGLISHDIR)/security/2002/dsa-134.data"
#use wml::debian::translation-check translation="6822acd35ad6eb7044786082d7d0deb96747c492"
|
