path: root/swedish/security/2008/dsa-1576.wml

#use wml::debian::translation-check translation="b128ca5f062ffd92dfde8a7b5888d4e87ec075f2" mindelta="1"
<define-tag description>förutsägbar slumptalsgenerator</define-tag>
<define-tag moreinfo>
<p>
Den nyligen publicerade sårbarheten i Debians openssl-paket
(<a href="/security/2008/dsa-1571">DSA-1571-1</a>,
<a href="https://security-tracker.debian.org/tracker/CVE-2008-0166">CVE-2008-0166</a>)
påverkar indirekt OpenSSH.
Därför måste alla användar- och värdnycklar som skapats med trasiga
versioner av openssl-paketet anses vara otillförlitliga, även efter att
openssl-uppdateringen har installerats.
</p>

<p>1. Installera säkerhetsuppdateringarna</p>

<p>
Denna uppdatering innehåller ett beroende på openssl-uppdateringen och
kommer automatiskt installera en rättad version av libssl0.9.8-paketet, samt
det nya paketet openssh-blacklist.
</p>

<p>
När uppdateringen har installerats kommer svaga användarnycklar automatiskt
att avvisas när så är möjligt (även om de inte alltid kan identifieras).
Om du använder sådana nycklar för autentisering av användare kommer de
omedelbart att sluta fungera och måste ersättas (se steg 3).
</p>

<p>
OpenSSH-värdnycklar kan omskapas automatiskt när
OpenSSH-säkerhetsuppdateringen installeras.
Uppdateringen kommer be dig om bekräftelse innan den gör det.
</p>

<p>2. Uppdatera OpenSSH:s known_hosts-filer</p>

<p>
När värdnyckeln omskapas kommer det att göra så att en varning visas när du
ansluter till systemet med SSH fram till att värdnyckeln uppdaterats i filen
known_hosts.
Varningen ser ut som följer:
</p>

<pre lang="en">
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
</pre>


<p>
I det här fallet har nyckeln helt enkelt ändrats, och du bör uppdatera
motsvarande known_hosts-fil, enligt beskrivningen i felmeddelandet.
</p>

<p>
Vi rekommenderar att du använder en betrodd kanal för att hämta
servernyckeln.
Nyckeln finns i filen /etc/ssh/ssh_host_rsa_key.pub på severn; dess
fingeravtryck kan skrivas ut med kommandot:
</p>

      <p>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</p>

<p>
Förutom användarspecifika known_hosts-filer kan det finnas en systemglobal
fil för kända värdar som heter /etc/ssh/ssh_known_hosts.
Denna fil används både av ssh-klienten och av sshd för
hosts.equiv-funktionalitet.
Även denna fil behöver uppdateras.
</p>

<p>3. Kontrollera samtliga OpenSSH-användarnycklar</p>

<p>
Den mest säkra lösningen är att skapa alla OpenSSH-användarnycklar på nytt,
förutom när det är möjligt att med hög sannolikhet avgöra att nyckeln har
skapats på ett system som inte påverkats av problemet.
</p>

<p>
Se om din nyckel påverkas genom att köra verktyget ssh-vulnkey, vilket
medföljer denna säkerhetsuppdatering.
Som standard kommer ssh-vulnkey att se på standardplatsen för
användarnycklar (~/.ssh/id_rsa, ~/.ssh/id_dsa och ~/.ssh/identity), din
authorized_keys-fil (~/.ssh/authorized_keys och ~/.ssh/authorized_keys2),
samt systemets värdnycklar (/etc/ssh/ssh_host_dsa_key och
/etc/ssh/ssh_host_rsa_key).
</p>

<p>
För att kontrollera alla dina egna nycklar, förutsatt att de finns på
standardplatser (~/.ssh/id_rsa, ~/.ssh/id_dsa, eller ~/.ssh/identity):
</p>

     <p>ssh-vulnkey</p>

<p>
För att kontrollera alla nycklar på ditt system:
</p>

     <p>sudo ssh-vulnkey -a</p>

<p>
För att kontrollera en nyckel på en icke-standardiserad plats:
</p>

     <p>ssh-vulnkey /sökväg/till/nyckel</p>

<p>
Om ssh-vulnkey säger <q>Unknown (no blacklist information)</q> (okänd
&ndash; svartlisteinformation saknas) så saknas information om huruvida
nyckeln påverkas.
I detta fall kan du se på modifieringstidpunkten (mtime) för filen genom att
använda <q>ls -l</q>.
Nycklar som skapats tidigare än september 2006 påverkas inte.
Tänk dock på att, även om det är osannolikt, så kan
säkerhetskopieringsprocedurer ha ändrat fildatumet bakåt i tiden (eller så
kan systemklockan ha varit felinställd).
</p>

<p>
Om du är osäker skapar du en ny nyckel och tar bort den gamla från alla
servrar den använts på.
</p>

<p>4. Omskapa eventuella påverkade användarnycklar</p>

<p>
OpenSSH-nycklar som används för användarautentisering måste skapas om
manuellt, och det gäller även de som har överförts till ett annat system
efter att de skapades.
</p>

<p>
Nya nycklar kan skapas med ssh-keygen, t.ex:</p>

<pre lang="en">
   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/användare/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/användare/.ssh/id_rsa.
   Your public key has been saved in /home/användare/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 användare@värd
</pre>

<p>5. Uppdatera authorized_keys-filer (om nödvändigt)</p>

<p>
När användarnycklarna har omskapats måste de relevanta öppna nycklarna
kopieras till alla authorized_keys-filer (och authorized_keys2-filer, om de
behövs) på fjärrsystem.
Se till att ta bort de rader som gäller gamla nycklar från dessa filer.
</p>

<p>
Förutom motvapen för att avhjälpa slumptalssårbarheten rättar även denna
uppdatering av OpenSSH flera andra sårbarheter:
</p>

<p><a href="https://security-tracker.debian.org/tracker/CVE-2008-1483">CVE-2008-1483</a>:
Timo Juhani Lindfors upptäckte att SSH-klienten, om X11-vidaresändning var
aktiverat, valde en X11-vidaresändningsport utan att försäkra sig om att den
kan bindas till alla adressfamiljer.
Om systemet är konfigurerat med IPv6 (även om det inte har fungerande
IPv6-konnektivitet) kunde detta göra det möjligt för en lokal angripare på
fjärrservern att kapa X11-vidaresändning.
</p>

<p><a href="https://security-tracker.debian.org/tracker/CVE-2007-4752">CVE-2007-4752</a>:
Jan Pechanec upptäckte att ssh faller tillbaka till att skapa en betrodd
X11-kaka om det inte går att skapa en obetrodd kaka, vilket möjligen kan
exponera den lokala skärmen till en skadlig fjärrserver när
X11-vidaresändning är aktivt.
</p>

<p>
För den stabila utgåvan (Etch) har dessa problem rättats i version
4.3p2-9etch1.
För närvarande har bara en delmängd av alla de arkitekturer som stöds
byggts, ytterligare uppdateringar kommer tillhandahållas när de blir
tillgängliga.
</p>

<p>
För den instabila utgåvan (Sid) och uttestningsutgåvan (Lenny)
har dessa problem rättats i version 4.7p1-9.
</p>

<p>Vi rekommenderar att ni uppgraderar era openssh-paket och vidtar de
åtgärder som beskrivs ovan.</p>
</define-tag>

# do not modify the following line
#include "$(ENGLISHDIR)/security/2008/dsa-1576.data"