Enkele OpenSSL-versies getroffen door ernstig lek - update

De OpenSSL-ontwikkelaars brengen donderdag een nieuwe versie van hun software uit die een ernstig beveiligingsprobleem moet verhelpen. Vooral servers gebruiken OpenSSL voor het aanbieden van ssl/tls-verbindingen.

De ontwikkelaars maken nog niet bekend om welk probleem het precies gaat. Ze melden wel dat het lek de classificatie 'ernstig' heeft gekregen. Dit betekent dat de kans groot is dat kwaadwillenden het misbruiken. De komende 1.0.2d- en 1.0.1p-releases verhelpen het lek, dat alle versies behalve 1.0.0 en 0.9.8 heeft getroffen.

Servers gebruiken OpenSSL vaak voor het aanbieden van ssl- en tls-verbindingen. Ook sommige browsers en besturingssystemen voor eindgebruikers, zoals Linux-distributies, gebruiken de ssl-bibliotheek. Google gebruikte OpenSSL tot vorig jaar in Chrome OS en Android, maar maakte uiteindelijk een eigen implementatie van de software.

Het OpenSSL-project heeft een onstuimige tijd achter de rug. Vorig jaar zorgde de zogenoemde Heartbleed-bug ervoor dat een deel van het interne geheugen van servers en clients met OpenSSL uit te lezen was. De bug ontketende een storm van kritiek op OpenSSL, dat slecht onderhouden zou zijn. Later bleek OpenSSL minstens nog een ernstig lek te bevatten.

Update, 20.25 uur - De 1.0.2d- en 1.0.1p-releases verhelpen het lek juist, in plaats van wat eerder stond geschreven. Het artikel is hierop aangepast.

Reacties (59)

Als het dus tegenzit, binnenkort weer allerlei produkten van Citrix upgraden, zoals de Netscalers maar ook end-user applicaties zoals een FileZilla (client of server) en natuurlijk de kernel van, later bekend te maken, Linux-distro's. Grote kans dat OSX ook een update gaat krijgen alsmede een aantal cross-platform browsers.

Kan ik me er druk om maken? Nee, security leaks zijn aan de orde van de dag, afhankelijk in welke business je werkt. Aan het eind van de dag is updaten/upgraden een service naar mijn klanten en een kopzorg minder dat ik om half 3 ''s ochtends op zondag een aantal webservers zou kunnen restoren vanaf backup omdat een onverlaat/script-kiddie de hele bende heeft platgegooid.

Een voorbereide IT'er is een tevreden IT'er

Dat is leuk, maar mijn 2 jaar oude router krijgt écht geen upgrades meer. Laat staan oudere hardware van Dell of Cisco. Enige wat je daar mee kan doen is custom firmware of eruit gooien en nieuw kopen.

Laat staan oudere hardware van Dell of Cisco.

Ik weet niet waar je precies op doelt maar veel hardware van Dell of Cisco wordt wel langer dan 2 jaar ondersteund.

Ik heb hier nog servers met DRAC kaarten die al een tijd geen nieuwe firmware meer krijgen.

Maar die hangen toch zeker niet direct aan het internet mag ik hopen?

Die hebben SSL:

RACADM CLI and Web-based interface operation, which supports 128-bit SSL encryption and 40-bit SSL encryption (for countries where 128-bit is not acceptable)

Grappig genoeg zouden die direct aan het internet theoretisch veiliger kunnen zijn dan via een openvpn-server die gebruik maakt van openssl.

[Reactie gewijzigd door Soldaatje op 7 juli 2015 22:00]

Met 40bits ssl (staat vast standaard aan als fallback) direct aan het internet... uhm, nou, liever niet lijkt me.

Idd. "De standaard" is tegenwoordig 2048 bits. Ook google voert dat in op de onderlinge communicatie van zijn servers.

40bits is binnen no time gekraakt, daar is tegenwoordig voldoende power voor.

2048 bit encryptie voor de key exchange misschien. Na het uitwisselen van de secrets wordt er "gewoon" een algoritme als AES gebruikt, en dus bijvoorbeeld 128 of 256 bit versleuteling.

Neem bijvoorbeeld DHE-RSA-AES128-SHA256, dat beschrijft dat er DHE-RSA wordt gebruikt voor de key exchange, daarna wordt er AES-128 gebruikt voor de versleuteling (en SHA2-256 om te controleren of pakketten authentiek zijn).

De 2048 bits gaat dan over de Diffie Hellman / RSA Key Exchange.

Klopt, maar de werkelijke sessie sleutel (128 bits) is er dan een die uit de random generator gekomen is en regelmatig vervangen hoort te worden.

De fallback key is een lachertje, het is juist een van de problemen die afgelopen jaar is aangepakt (als je gepatched hebt)... Zat overigens in vrijwel alle stacks.

[Reactie gewijzigd door tweaknico op 8 juli 2015 18:56]

Ter aanvulling: de uiteindelijke master secret wordt gemaakt met random data van beide kanten van de verbinding. Een zwakke RNG aan een kant is dus niet meteen fataal.

Mogelijk is dit voor veel mensen een handige optie:

OneRNG - http://onerng.info/

Dit zorgtervoor dat er meer entropie in de PRNG van je OS wordt opgenomen.

"40bit ssl" is 40bit DES of RC2 (kan een beetje pc direct forceren)
"128bit ssl" is waarschijnlijk 128bit AES of, indien het echt oud is een van de andere met 128bit support (zie https://en.wikipedia.org/...ort_Layer_Security#Cipher)

Dat is leuk, maar mijn 2 jaar oude router krijgt écht geen upgrades meer.

Het beste zou het zijn als je bij de fabrikant gaat klagen. Misschien zou je zelfs bij de winkel aanspraak kunnen maken op garantie. Er zitten duidelijk fouten in en 2 jaar valt binnen de te verwachten levensduur van een router.

DDWRT?

neem je toch gewoon een Palo Alto? kost je wel ff wat, maar dan heb je ook wat

1.0.1e is al ruim een jaar oud dacht ik.

Wel apart dat het lek ook in 1.0.2d zit,. op de site staat 102c als de laatste versie.
https://www.openssl.org/source/

Hoe kan dat?

De versies die in het artikel genoemd zijn lossen het probleem op. Degene die het artikel heeft geschreven heeft de announcement van OpenSSL niet goed gelezen.

inmiddels is het artikel aangepast "Update, 20.25 uur - De 1.0.2d- en 1.0.1p-releases verhelpen het lek juist, in plaats van wat eerder stond geschreven. Het artikel is hierop aangepast."

Het lek zit niet in 1.0.2d en ook niet in 1.0.1p.
Dat zijn juist de versienummers die het lek gaan dichten.

Het accepteren van dit soort lekken door te stellen dat het erbij hoort vind ik te makkelijk. Er zijn genoeg software alternatieven waarbij wel in de ontwerpfase al is nagedacht over beveiliging. Kwestie van zoeken en iets anders durven proberen.

Een kritische IT'er is een professionele IT'er.

Er is natuurlijk per definitie nagedacht over beveiliging bij OpenSSL... dat is tenslotte het hele doel van de software.

Maar al die encryptie-varianten zijn nogal complex en OpenSSL implementeert veel van de details. En blijkbaar is het in de loop der jaren uitgegroeid tot een lastig te doorgronden geheel.
Dat zie je ook bij de redenaties waarom o.a. LibreSSL, Google's en Amazon's alternatieven zijn gemaakt; alle (delen van) protocollen die toch niet meer gebruikt zouden moeten worden schrappen en opnieuw beginnen met wat er dan overblijft.

Netscaler krijgt wel erg veel updates inderdaad, dat is net als MS patches amper nog bij te houden.

Nu is upgraden voor de meeste bedrijven niet perséé direct noodzakelijk, wie gaat er tenslotte inbreken op inloggen.mijnkleinbedrijfje.nl waar normaal gesproken 10 medewerkers van gebruik maken en dan nog zijn ze nog niet in je netwerk want die dingen hangen vaak in een DMZ.

Bovendien zal het lek waarschijnlijk gaan over het ontsleutelen van informatie en niet zo zeer over het inbreken in het systeem. Dit is meer ernstig voor bijv. banken -en verzekeraars of overheidssites.

Dan heb je niet begrepen hoe de inbraak industrie tegenwoordig werkt.
Er wordt gewoon geprobeerd om op Alle adressen in de wereld in te breken. En je bent gewoon een van de hits ....
Driveby shooting.

OpenSSL zit niet in de Linux kernel. De OpenSSL library is voornamelijk user space.

Het is uitsluitend userspace.

Zomaar alles naar de nieuwste versie updaten is ook niet altijd de beste methode, aangezien daar ook nog wel eens bugs/leaks in kunnen zitten waardoor je alsnog om half 3 zondag 's ochtend het bed uit moet.

Waarom moet je op zondag je bed uit voor een bug die er al een hele tijd in zit? Security is belangrijk maar soms kun je ook overdrijven

Wij hebben gewoon de autoupdates aan op de servers. Zolang je geen vreemde repositories installeert die hun pakketten niet goed testen is er weinig dat fout kan gaan. Het draait al jaren automatisch en goed en we zijn altijd uptodate met de laatste fixes. Hoeft niemand z'n bed voor uit

Omdat bijvoorbeeld zoals hier vermeld is, de laatste release een serieus security bug heeft, het zit niet in eerdere versies. Die staat dan meteen op je systeem.

[Reactie gewijzigd door gjmi op 8 juli 2015 21:00]

Nee, juist andersom. Met de updates krijg je een versie waar het probleem niet meer in voor komt. In de iets oudere versie heeft het wel gezeten, maar dat is niet anders dan alle nog niet gevonden lekken in bv 0.9.8 als je een ouder systeem hebt die sowieso geen updates installeert.
Iedere software heeft bugs, dus dan kun je maar beter versies hebben waarin in ieder geval de bekende lekken zijn gedicht.

Fout, donderdag komt de patch. Als je nu de laatste versie hebt, heb je mogelijk een probleem.

En als je niet de laatste versie hebt, heb je niet alleen dit probleem maar ook andere allang al gepatchte problemen.

FYI, de end user kant (vservers) van NetScaler gebruikt geen OpenSSL. Enkel het administratief deel (maken van keys, requests, import/export van PKCS#12) maakt er gebruik van (en is dus ook niet exposed).Maw, er is op vlak van NetScaler geen gevaar.

Elke dag updaten/upgraden? Dat noem je een service? Niet eerst even testen ofzo maar gewoon op de automaat de kernel even updaten? Zou geen dienst willen afnemen met zulke voorwaarden.

getroffen door? alsof het een ziekte is die je per pngeluk oploopt. Ernstige fout in OpenSSL versie gevonden lijkt mij toepasselijker. En dat vlak nadat we een groot SSL lek net hebben gevonden en opgelost. Naam staat me even niet bij.....

En iedereen maar roeptoeteren dat Open Source Software HELEMAAL het einde zou zijn en door de grote hoeveelheid mensen die er aan meewerkt dit soort fouten door het 'proces' niet meer mogelijk zou zijn.

En iedereen maar roeptoeteren dat Open Source Software HELEMAAL het einde zou zijn en door de grote hoeveelheid mensen die er aan meewerkt dit soort fouten door het 'proces' niet meer mogelijk zou zijn.

Dat zal niemand garanderen, maar *als* er meerdere mensen naar kijken, is de *kans* op het vinden van bugs groter. Het verschil tussen OS en CS is dat bij OS in pricipe iedereen er naar kan kijken, het zij zelf of iemand daarvoor inhuren. Bij CS heb je geen idee wie er naar kijkt, is het een enkele dev, is het een team (met wellicht last van tunnelvisie), wordt er geld uitgegeven aan audits? Niemand die dat weet zonder verklaring van de CS eigenaar.

BTW in hoeverre is het toeval dat bv de MS SSL lib ook enkele vulnerabilities zijn gevonden, bv
MS14-066 en MS15-031. Deze zitten in alle supported versies, maar waarschijnlijk ook in unsupported versies (lees het nog altijd redelijk populaire XP). Als die lib OS zou zijn zou iedereen (1 persoon zou al voldoende zijn) met wat kennis een backport kunnen maken (van de patch of een nieuwe versie).

Dat zal niemand garanderen, maar *als* er meerdere mensen naar kijken, is de *kans* op het vinden van bugs groter. Het verschil tussen OS en CS is dat bij OS in pricipe iedereen er naar kan kijken, het zij zelf of iemand daarvoor inhuren.

Daarmee is de sterkte van OS ook meteen de zwakte. Iedereen kan er naar kijken, ook diegenen die er totaal geen belang bij hebben om gevonden zwakheden te melden. Omdat het niet de vraag is óf er fouten in grote complexe software zit, maar wanneer deze fouten gevonden worden (OS zal over het algemeen niet meer of minder fouten bevatten dan CS).
Bij OS is het veel makkelijker om fouten te vinden, omdat iedereen vrij toegang heeft tot de broncode. Het probleem is dat organisaties/ bedrijven die misbruik van dergelijke fouten willen maken net iets talrijker en meer gemotiveerd zijn en meer geld hiervoor beschikbaar hebben dan de goedwillende organisaties. (Om het even gechargeerd te zeggen: Bij CS zit er verplicht een backdoor in voor de NSA, Bij OS zijn er beveiligingslekken gevonden door de NSA en alle grote veiligheidsdiensten, foute beveiligingsbedrijven en misdaadorganisaties, die die lekken kunnen gebruiken totdat een goedwillende programmeur of organisatie over datzelfde lek struikelt.)

Dit is geen pleidooi om OS af te zweren ten gunste van CS. Maar houd a.u.b. ook de zwakheden van OS goed in de gaten.

Maar houd a.u.b. ook de zwakheden van OS goed in de gaten.

Welke zwakheden zijn dat dan? Je geeft al aan dat alles bugs bevat, dat mensen dus bugs vinden in OS en die niet melden doet dan niet terzake immers hoe verklaar je al die gevonden bugs in CS? Voor het vinden van bugs en het maken van exploits is geen source nodig, voor het fixen ervan wel (over het algemeen).

Nee, Closed source is pas de shit, waarbij het melden van een lek uitdraait op rechtszaken en doofpotpraktijken.. Ik ben niet iemand die voor het een of het ander kiest "OMDAT FANBOY BLABLA" maar bij het ontdekken van dit soort lekken is er vaak in ieder geval een grote groep mensen die er direct aan een oplossing gaan werken..

En iedereen maar roeptoeteren dat (...) door de grote hoeveelheid mensen die er aan meewerkt dit soort fouten door het 'proces' niet meer mogelijk zou zijn.

Onzin, niemand met een beetje verstand van programmeren beweert dat fouten niet mogelijk zijn, door wat voor proces dan ook.

Waar ik me vooral over verbaas is dat er zoveel (grote commerciële zoals Google) partijen gebruik maken / maakten van OpenSSL en tegelijkertijd de code (nog steeds) van een discutabele reputatie is. Waar zijn de zakken met geld en ontwikkelaars om bijvoorbeeld een serieuze audit te laten doen zoals ook bij TrueCrypt is gebeurt.

Je bent bij OS ten minste instaat om desnoods ZELF een oplossing te maken en uit te voeren.
Niet dat het makkelijk zal zijn maar het KAN.

Als je om een of andere reden veroordeeld bent om nog een tijdje met XP te werken dan ben je pas de sjaak, Niemand die het voor je gaat oplossen, ook niet de al bekende problemen die ook in de MS stack zitten. ....

Gelukkig heeft synology (nog?) de versie 1.01o (de o van OTTO) met de laatste firmware update http://tweakers.net/downl...anager-52-build-5592.html

Of is deze oudere versie (o kom voor p) ook lek ?

Nu ook KODI nog.

[Reactie gewijzigd door Dr.Jake op 7 juli 2015 20:03]

Ja, deze is lek. De p-versie lost het juist op.

1.0.1o is dus lek, en daarom komt er 1.0.1p.
Dus de p-versie is niet meer lek.

Jemig... Als je al jaren op 0.98 zit ben je niet vatbaar voor dit lek en ook nooit vatbaar voor hearbleed geweest.

Trekt toch het dogma van 'alles meteen updaten' wel in twijfel Natuurlijk kan het net zo goed andersom zijn geweest maar het is wel frappant. Zou ook kunnen wijzen op minder zorgvuldigheid bij het OpenSSL team tegenwoordig.

[Reactie gewijzigd door GekkePrutser op 8 juli 2015 00:59]

Dat 'alles meteen updaten' slaat normaal gesproken op security patches of op patches die datacorruptie of downtime moeten voorkomen. Altijd maar bleeding edge willen draaien is inderdaad meestal onverstandig.

Eigenlijk moet je vooral kijken naar hoelang een al gereleaset product fatsoenlijk wordt ondersteund met security patches. Een beheerder in een corporate omgeving moet geen genoegen nemen met nieuwe features die daarbij door de strot worden geduwd. Goede ondersteuning is simpelweg het accepteren dat mensen "oude" versies draaien als het gaat om features en API-compatibiliteit. Het dichten van een lek in bijvoorbeeld OpenSSL verandert normaal gesproken niets aan de rest van een applicatie.

Kijk dus niet alleen naar versienummers, maar kijk naar hoe lang oudere versies ondersteund worden en naar hoe wordt omgegaan met het releasen van security patches. Soms worden "oudere" versies bijvoorbeeld pas later gepatcht omdat de softwaredeveloper graag eerst de nieuwste versie patcht. Dat is dus afhankelijk van hoe de developers kijken naar "nieuw" en "oud".

Een fatsoenlijk opererend bedrijf gooit -als er een vulnerability is gevonden- er een team developers tegenaan om alle gangbare versies te patchen en te testen. Dat wordt door developers niet als het meest spannende werk ervaren, dus als je bijvoorbeeld software bouwt die je lang moet ondersteunen, kan dat een uitdaging zijn. Denk aan Red Hat met 10 jaar support.

Ik heb mijn gebruikers maar gemailed dat we donderdag of vrijdag misschien wel alles moeten rebooten en dat ze dus rekening moeten houden met kleine verstoringen. Gelukkig proberen wij alles zo te bouwen dat we het kunnen onderhouden zonder onderbreking van de dienstverlening maar voor sommige diensten is dat de moeite gewoon niet waard.
Het vervelendste is misschien nog wel dat we de komende twee weken bij ieder fout gemailed gaan worden met de vraag of het misschien te maken heeft met de bug in OpenSSL en/of de bijhorende reboot.

Gelukkig kun je vaak zelf ook de meeste Windows programmatuur bijwerken met een nieuwe OpenSSL versie door de nieuwe DLL bestanden in de programma directory te plaatsen. Dit werkt bijvoorbeeld goed bij FlashFXP.

Iemand een bron waaruit blijkt dat deze ernstige (high) bug misbruikt wordt in de praktijk?
Dan hadden ze dat wel gemeld toch, en de source direct vrijgegeven ipv donderdag.
En als de source nog niet klaar is dan hadden ze dat ook wel gemeld en een andere tijdelijke oplossing geadviseerd.

Wellicht een goed idee om mdeb-TLS wat meer onder de aandacht te brengen. Ook een open-source software SSL pakket en sinds kort overgenomen door ARM. Zover ik weet zijn daar een stuk minder problemen mee. Ik gebruik het zelf in mijn software en vind het ook een stuk makkelijker om mee te werken dan OpenSSL.

Dit jaar was natuurlijk nog wel een lekje gevonden nieuws: Kwetsbaarheid in PolarSSL maakt uitvoeren van malafide code mogelijk. Er zijn ook nog andere programma's het overwegen waard, als je niet voor OpenSSL wil gaan, GnuTLS OpenSSL-forks, NSS, Botan ... vast veel meer dan ik ken. s2n is misschien ook nog interessant om te volgen. (niet alle alternatieven zijn compleet, libcrypto en libssl-vervangend natuurlijk zoals hieronder terecht wordt opgemerkt.)

[Reactie gewijzigd door begintmeta op 7 juli 2015 20:43]

Iedereen maakt fouten. Dat is het probleem niet. De vraag is hoe er mee omgegaan wordt. Zover ik in het verleden heb gelezen stonden / staan de OpenSSL ontwikkelaars niet bijster open voor feedback. Bij PolarSSL is dat een minder groot probleem. Dezelfde kritiek heb ik vorige week ook (beter onderbouwd) bij Kodi.

Dat is een goed punt natuurlijk, men moet openstaan voor kritiek, aangezien fouten nu eenmaal worden gemaakt. Het is op het eerste gezicht soms wel lastig in te schatten hoe open men voor kritiek staat.

Wat ik me afvraag is of bijvoorbeeld gebruik van Ada (of andere programmeertalen) (met wrappers voor C etc) de kans op bepaalde fouten zou verkleinen. Of in hoeverre een project zoals nieuws: Nicta maakt 'veilige' SeL4-microkernel opensource ook voor een TLS bibliotheek zinvol zou kunnen zijn (en of zoiets überhaupt zinvol is).

Klopt, niks is 100% foutvrij of 100% veilig. Deze bug was er echter wel een die niet standaard op ieder systeem, dat PolarSSL/mbed TLS gebruikt, te misbruiken was. Heel wat anders dan een Heartbleed.

En nee, s2n is om meerdere redenen niet interessant. Het heeft nog lang niet alle SSL functionaliteit geimplementeerd en heeft nog een lange weg te gaan voordat het zelf heeft bewezen als stabiele en veilige SSL library. En waarom iets nieuws beginnen als er al iets goeds is?

Daarbij, ik ken een van de mbed TLS ontwikkelaars persoonlijk. Gezien zijn cryptokennis houd ik het lekker bij mbed TLS.

Amazon heeft in 6000 regels source code een TLS library geschreven en belooft deze ook te onderhouden. Zelden gebruikte opties zijn geschrapt. Als de feutures die jij wilt gebruiken erin zitten lijkt dit me een mooi alternatief voor mdeb-TLS.

https://blogs.aws.amazon....Source-TLS-Implementation

#include <openssl/aes.h>

Gebruikt de crypto van OpenSSL, dus het is niet volledig onafhankelijk. Ik vermoed dat het later de bedoeling is dat ook te vervangen, maar op dit moment vind ik het geen goed alternatief.

Het is trouwens "mbed TLS".

Ik ben in mijn open source project een paar jaar geleden overgestapt van OpenSSL naar mbed TLS (het voormalige PolarSSL). Die stap had ik veel eerder moeten maken. In tegenstelling tot OpenSSL is mbed TLS goed gedocumenteerd (inclusief een hoop kleine voorbeeld programma's), heeft het een eenvoudige API (geen vieze callback-meuk om het werkend te krijgen) en is het nette en veilige code. Alle OpenSSL bugs en bijbehorende ellende zijn aan mij en mijn gebruikers mooi voorbij gegaan. Ik durf zelfs te stellen dat mbed TLS initiatieven zoals LibreSSL totaal overbodig maken.

Ben je een softwareontwikkelaar die OpenSSL gebruikt, dan adviseer ik je dringend om eens naar mbed TLS te kijken. Daar ga je zeker geen spijt van krijgen. De migratie van OpenSSL naar PolarSSL was voor mij toentertijd een minimale inspanning.

[Reactie gewijzigd door Faeron op 7 juli 2015 20:26]