Kæmpe Linux-hul levede i to år

Linux-distributionerne Debian og Ubuntu har været hullede som en si i de sidste to år. En misforstået rettelse gjorde, at systemets nøgler til kryptering kan forudsiges. Fejlen berører alle de nøgler, der er generereret med systemet - også efter at softwaren er opdateret.

Linux-distribution Debian, som ellers har et pænt rygte for sin sikkerhedsmæssige kvalitet, har måtte inkassere et syngende lussing, efter at det er kommet frem, at styresystemet i de sidste to år har levet med en gigantisk sikkerhedsbrist.

Sikkerhedseksperten Luciano Bello har opdaget, at en algoritme som fremstiller tilfældige tal til brug for kryptering er forudsigelig.

Algoritmen var en del af Debians OpenSSL-bibliotek. Fejlen betyder, at nøgler, som benyttes til kryptografi, kan gættes. Det gælder nøgler til
SSH, SSL og OpenVPN.

Det er ikke nok at opdatere softwaren for at fjerne problemet. Alle nøgler, som er genereret med den fejlbehæftede software, skal kasseres. Det gælder også nøgler, som er blevet importeret til andre systemer.

Fejlen opstod i september 2006, da det statiske analyseværktøj Valgrind blev anvendt til at finde fejl i Debian-koden. Debian-udviklere uden viden om kryptografi fjernede på baggrund af resultaterne fra Valgrind tilfældig information i algoritmerne, som benyttes til at forstærke nøglerne.

Men problemet er ikke begrænset til én Linux-variant. Debian benyttes som grundlag for en række andre Linux-distributioner, herunder den populære Ubuntu. Disse afledte distributioner er også berørt af fejlen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kristian Thy

Debian-udviklere uden viden om kryptografi fjernede på baggrund af resultaterne fra Valgrind tilfældig information i algoritmerne, som benyttes til at forstærke nøglerne.

Hvis man fikser noget efter at have kørt valgrind må man jo mene man har fundet en bug. Hvorfor implementerer man så Debian-specifikke fixes i stedet for at prøve at sende dem upstream til openssl-udviklerne (hvor man så havde fået klar besked om at holde nallerne væk)?

  • 0
  • 0
Pascal d'Hermilly

For Debian er det Etch og indtil nu.
For Ubuntu er det 7.04 og indtil nu.
Jeg kender ikke de andre derivater.

Der gen-autogenereres nøgler til services installeret via pakkesystemet. Dvs. f.eks. ssh, apache-ssl og andre. Hvis du har brugt openssl til manuelt at skabe et certifikat vil det ikke blive fikset automatisk.

Det største problem er at du vil få en anden ssl-signatur så f.eks en bruger der har ssh'et til dig før vil blive mødt af følgende besked:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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.
The fingerprint for the RSA key sent by the remote host is
54:96:e1:b2:db:df:71:1d:65:bd:8c:8d:2d:02:dd:32.
Please contact your system administrator.
Add correct host key in /home/pascal/.ssh/known_hosts to get rid of this message.
Offending key in /home/pascal/.ssh/known_hosts:3
RSA host key for dhermilly.dk has changed and you have requested strict checking.
Host key verification failed.

Når signaturen er ændret så prøver ssh-klient at advare om at der måske kan være noget galt.
Man kan sikkert lave en smart ssh option så man kan stole på den nye signatur(efter at have tjekket om den er korrekt).
Ellers må redigere i filen .ssh/known_hosts. I mit tilfælde fjerne linje 3.

  • 0
  • 0
Kristian Thy

Sune:

Patchen har været rundt om Openssl ...

Det blev det så kun værre af:

What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG.

NEEEEEEEEEEEEEEEEEEEEEEEJ!

Ja, bagklogskabens ulideligt klare lys og alt det der - men hvis man skriver sådan noget der, så skal advarselslamperne lyse; man er lige lukt på vej i "famous last words"-fælden.

Men - og her håber jeg på at der er nogen der gider sætte sig ind i sagerne for mig ;) - hvis den er accepteret af openssl-dev, hvorfor er det så kun debian der er ramt? Det burde jo så have bredt sig til alle andre openssl-pakker ... jeg kan ikke tro fx Fedora ikke har opdateret openssl i knap to år.

  • 0
  • 0
Peter Mogensen

... ja.

Men jeg vil også vove at påstå at selvom openssl-dev folkene ikke svarede og ham, der svarede tilsyneladende ikke satte sig ordentlig ind i hvad det faktisk var han svarede på, så har Debian-maintaineren håndteret sagen forkert.

Når en bruger åbener en bug-report om at han gerne så det gjort nemmere at debugge med Valgrind, så er det ikke en så akut rettelse at man blot skal patche lokalt i debian-pakken. Jeg kan ihvertfald ikke se nogen grund til at man ikke bare submittede den aktuelle patch upstream og ventede på at den kom tilbage istedet for blot at spørge på mailinglisten.
Skulle man endelig have med et upstream-produkt at gøre, hvor det var for omstændligt at vente på at få vurderet en patch, så kunne man vel nøjes med at lave en #ifdef (som der jo allerede var) så folk, der ønsker at debugge kan downloade source-pakken og re-kompilere.

  • 0
  • 0
Henrik Christian Grove

Efter at have (fået) genereret nye host-nøgler, så vil gode systemadministratorer neturligvis køre

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key

og sende uddata til alle brugerne, så de udover bare at slette den gamle nøgler fra deres known_hosts fil også kan se om det nye fingerprint rent faktisk kommer fra den rigtige maskine.

Og jo, det bør selvfølgelig sendes forseglet som anbefalet brev (gammeldags post) for at mindske risikoen for at nogen kan pille i det.

Husk også at køre

ssh-vulnkey (er i Debians nye openssh-server-pakke) på alle nøgler på dine systemer så du kan fjerne adgangen for brugere der har sårbare nøgler.

  • 0
  • 0
Peter Makholm Blogger

200K nøgler passer meget godt.

Problemet er at de eneste tilfældige inddata til genereringen af ssh-nøgler har været process-ID for ssh-keygen processen.

PID løber på et normalt linuxsystem fra 1 til 32K. Dette skal ganges med forskellige arkitektur-variationer af hvordan PID'et bliver brugt i tilfældighedsgeneratoren. Det er vist kun 32bit/64bit samt little/big endian der er relevant.

Det burde blive cirka 128K forskellige nøgler der kan genereres.

  • 0
  • 0
Log ind eller Opret konto for at kommentere