OpenSSL lukker i dag alvorligt sikkerhedshul med ny patch

9. juli 2015 kl. 11:167
Systemadministratorer og andre, der afhænger af OpenSSL, bør i dag være klar til at skifte til en ny version af open-source krypteringsbiblioteket. Patchen lukker nemlig et alvorligt sikkerhedshul.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

OpensSSL er et meget udbredt open-source software bibliotek, som tilbyder krypterede internetforbindelser gennem SSL/TLS forbindelser til rigtig mange hjemmesider.

Det skriver The Hacker News.

Artiklen fortsætter efter annoncen

De nye versioner af OpenSSL biblioteket hedder version 1.0.2d og 1.0.1p og er blevet udfærdiget for at lukke et sikkerhedshuller, som OpenSSL-holdet kaldet for ’meget alvorlig’. Fejlen har ikke været afsløret af andre kilder. Der er ikke flere detaljer om den mystiske sikkerhedsbrist endnu, bortset fra at den ikke er aktuel for 1.0.0 eller 0.9.8 serierne.

Patchen blev annonceret af OpenSSL-udvikler Mark J Cox i søndags på en mailingliste - dog uden at afsløre informationer, som kan bruges af hackere til at udnytte svagheden, før patchen er blevet udgivet.

Nogle sikkerhedseksperter har spekuleret i, om den nye og alvorlige bug kunne være endnu en ’Hearbleed’ eller ’POODLE’ fejl, som var to meget alvorlige softwarefejl, der stadig påvirker nogle dele af internettet i dag. OpenSLL-patchen vil blive offentliggjort i løbet af i dag.

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
4
9. juli 2015 kl. 16:55

Jeg savner, at artiklen sætter tingene lidt i perspektiv i stedet for at gå efter sensationen.

Fejlen er introduceret så sent, at man skal være yderst bleeding edge agtig for at være omfattet af fejlen. Således er alm. udgivelser af RHEL, CentOS, Ubuntu og Debian ikke omfattet.

(Det er muligt, at forskellige development-udgaver af ovennævnte er ramt. De nyeste Fedora Linux'er er ramt, fordi Fedora netop er en bleeding edge distribution; i det store billede retfærdiggør dette dog ikke, at man går i panik.)

2
9. juli 2015 kl. 15:38

Nu er der kommet en konkret beskrivelse af fejlen:

During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails...

(Læs linket for hele beskrivelsen)

Det lyder til kun at være kritisk for klienter og servere der anvender client side certifikater til authentifikation. Detmed lyder det til at en lang række server-ejere kan ånde lettet op – men client-side er fucked hvis man bruger OpenSSL. Heldigvis er der dog vist ikke nogle af de store browsere der bruger OpenSSL client-side, så den brede masse går nok også fri i denne gang?

1
9. juli 2015 kl. 12:09

Ikke alle mine masskinner bliver tændt dagligt. Måske en uge vil være fint. Inden de fortæller i detaljer hvad fejlen er.

3
9. juli 2015 kl. 16:49

Måske en uge vil være fint. Inden de fortæller i detaljer hvad fejlen er

Bent, hvordan skulle et kildekodebaseret projekt (open source, du ved) holde detaljerne skjult når det laver et nyt release? Med det samme releaset er offentliggjort, vil forskellen mellem den gamle og den nye kode afsløre præcist hvad det uhensigtsmæssige består i.

For denne fejl, som nu også er kendt som CVE-2015-1793: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1793) er forskellen i koden her: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365620a7b17fcce311ada93ad

OpenSSL har arbejdet på løsningen i stilhed siden 24/6-2015, for at kunne have et release klar til offentligørelsen af problemet.

Det du foreslår, vil kræve at OpenSSL skulle levere binære opdateringer til alskens mærkværdige arkitekturer og systembibliotekskombinationer, samt stå inde for validiteten og funktionaliteten af disse i en karensperiode, indtil man dømmer det "forsvarligt" at offentliggøre kildekoden. Det tror jeg næppe du får nogle fri software/open source source-projekter til.

Uanset, hvis dine maskiner er slukkede/offline er du da helt sikker på at sandsynligheden for uønsket udnyttelse af dem er nul. Bedre sikkerhed får du ikke andre steder :).

Mikkel

6
10. juli 2015 kl. 09:42

Bent, hvordan skulle et kildekodebaseret projekt (open source, du ved) holde detaljerne skjult når det laver et nyt release? Med det samme releaset er offentliggjort, vil forskellen mellem den gamle og den nye kode afsløre præcist hvad det uhensigtsmæssige består i.

Ja, og den som kan forstå det og finde det, er også dygtigt nok til at misbruge dette. Mener heller ikke at fejl, og sikkerheds brist, skal forsøges skjult.

Men kom til at tænke på den første rigtige orm til windows. Kan i huske den, der hvor man fik virus på 10-15 sec, og slet ikke kunne nå at patche inden man var indfikseret.

Har 3-4 PC som meget sjælden er tændt, og de kommer jo på Internet, inden der findes en ny opdatering på sammen. Så hvis fejlen var meget udbredt, og rigtigt farlig for slutbruger, så ville jeg være lidt betænkeligt, ved bare at starte op. Men det var ikke tilfældet denne gang.

Når vi næste gang ser sådan en orm, så tror jeg ikke vi skal regne med at payload er så pænt.