Opdater: Fejl i OpenSSH kan lække krypto-nøgler

15. januar 2016 kl. 14:297
Alvorligt sikkerhedshul i udbredt SSH-protokol giver hackere adgang til hukommelsen på tilsluttede computere.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Ifølge Ars Technica har sikkerhedsfirmaet Qualys afsløret et sikkerheds-hul i en af de mere udbredte secure shell (SSH) protokoller. Hullet giver ondsindede servere adgang til krypteringsnøgler og RAM hukommelsen på tilsluttede computere.

Sårbarheden skyldes en kodefejl, der giver adgang til eksperimental roaming i OpenSSH version 5.4 til 7.1. Fejlen ligger ikke på de versioner af protokollen som bruges på servere, men alene i den version slutbrugeren anvender for at forbinde sig til servere.

I en officiel meddelelse fra OpenSSH skriver man, at brugere af den sårbare udgave bør opdatere deres program straks, og at de, der ikke er i stand til at opdatere, bør deaktivere roaming ved at:

Tilføje UseRoaming no til den globale ssh_config(5) fil eller under brugerkonfigureringen ~/.ssh/config eller ved at taste UseRoaming=no på kommandolinjen.

Artiklen fortsætter efter annoncen

Qualys oplyser på seclists.org at hullet alene kan udnyttes, efter at slutbrugeren selv har bekræftet sig over for serveren, hvilket mindsker risikoen betydeligt for, at sikkerhedsbristen kan brede sig.

Regenerering af SSH nøgler anbefales

Udviklere hos Qualys mener dog, at hackere muligvis allerede har gjort brug af hullet hos kompromitterede servere med det formål at sikre fortsat adgang i tilfælde af, at deres oprindelige adgang skulle blive opdaget og lukket.

Sammenlignet med en anden sikkerhedsbrist i OpenSSL i 2014 (Heartbleed), som gjorde det muligt for hackere at udnytte stort set enhver hjemmeside kørende OpenSSL, så kan OpenSSH-hullet alene udnyttes, efter at en slutbruger selv har oprettet forbindelse til en ondsindet konfigureret server.

Oven på afsløringen af sikkerhedsbristen oplyser Qualys, at højt profilerede hjemmesider eller brugere kan have behov for at generere nye SSH-nøgler.

7 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
7
18. januar 2016 kl. 16:22

...begge parter i en sikker kommunikation har vel et nøglepar - og hvis serverens er blevet kompromitteret kan nogen opsnappe kommunikationen og udgive sig for at være den

Netop. "... hvis serverens er blevet kompromitteret ..." - og det er de ikke.

Fra Ars Technica artiklen:

The vulnerability resides only in the version end users use to connect to servers and not in versions used by servers. A maliciously configured server could exploit it to obtain the contents of the connecting computer's memory, including the private encryption key used for SSH connections.

6
18. januar 2016 kl. 16:05

Nu er jeg ikke super stærk i kryptografi, men begge parter i en sikker kommunikation har vel et nøglepar - og hvis serverens er blevet kompromitteret kan nogen opsnappe kommunikationen og udgive sig for at være den

5
18. januar 2016 kl. 11:50

...og hvad med de forskellige cloud udbydere (AWS, Google etc) hvor man forbinder via SSH....kan man forvente at de allerede har opgraderet OpenSSH (hvis det er dét de bruger) så man kan lave nye nøgler, eller skal man venter et par dage?

4
18. januar 2016 kl. 11:46

Det ser ud til den nyeste version af OpenSSH er "OpenSSH 7.1p2 released Jan 14, 2016"...dvs. den er meget ny! Hvis jeg har en Linux server (webserver), så skal jeg altså opgradere all OpenSSH pakker på denne? (tvivler på de allerede ligger i de forskellige repositories)...hvad gør man så? Og når OpenSSH så er opgraderet, så laver man nye client nøgler....er det rigtig forstået?

3
17. januar 2016 kl. 19:28

Men så er det vel stadig brugerne af disse services, og ikke hjemmesiderne, der skal have nye nøgler. SSH nøglerne findes slet ikke på hjemmesiderne men "hjemme" hos hver enkelt administrator/bruger. (Ellers er der et helt andet, mere seriøst sikkerhedsproblem.)

"Brugere ja, hjemmesider nej." holder stadig så vidt jeg kan se.

Ars Technica artiklen siger:

"This information leak may have already been exploited in the wild by sophisticated attackers, and high-profile sites or users may need to regenerate their SSH keys accordingly," they wrote.

Så vrøvlet er ikke opfundet af Version2, men vrøvl er det vist stadig ikke desto mindre, og er ikke blevet fanget af Version2.

2
17. januar 2016 kl. 16:24

Mange bruger SCP eller SSH på anden vis til at uploade data og administrere deres webservere.

1
15. januar 2016 kl. 16:30

Oven på afsløringen af sikkerhedsbristen oplyser Qualys, at højt profilerede hjemmesider eller brugere kan have behov for at generere nye SSH-nøgler.

Er det ikke noget vrøvl at en hjemmeside kan have en SSH nøgle? Det er SSH nøgler ikke HTTPS certifikater.

Brugere ja, hjemmesider nej.