OpenSSL bevat een of meer kritieke lekken

De ontwikkelaars van OpenSSL rollen donderdag een nieuwe versie uit, die een of meer ernstige beveiligingsproblemen moet oplossen. Vorig jaar kampte OpenSSL al met een groot lek, waardoor het interne geheugen van servers kon worden uitgelezen.

Om wat voor lek of lekken het gaat, is niet bekend; in de vooraankondiging van de versie geeft OpenSSL-ontwikkelaar Matt Caswell enkel aan dat een of meer kwetsbaarheden de classificatie 'ernstig' hebben. Die classificatie is gereserveerd voor beveiligingsproblemen waarvan de kans groot is dat ze worden misbruikt. Daarbij kan het bijvoorbeeld gaan om een denial of service, het uitvoeren van code of het uitlezen van gegevens uit het geheugen.

De bug kan zowel gevolgen hebben voor servers als voor eindgebruikers. OpenSSL wordt vaak gebruikt door servers om ssl/tls-verbindingen aan te kunnen bieden, maar ook sommige browsers en besturingssystemen voor eindgebruikers gebruiken de ssl-bibliotheek. Daaronder zijn de nodige Linux-distributies. Google gebruikte OpenSSL tot vorig jaar in Chrome OS en Android, maar heeft de software inmiddels geforkt tot een eigen versie. Die is echter gebaseerd op de code van OpenSSL, dus de kwetsbaarheid zou op die systemen nog steeds aanwezig kunnen zijn.

Vorig jaar kwam een grote bug in OpenSSL aan het licht. De Heartbleed-bug maakte het mogelijk om een deel van het interne geheugen van servers en clients met OpenSSL uit te lezen. De bug ontketende een storm van kritiek op OpenSSL, dat slecht onderhouden zou zijn; Google en OpenBSD besloten de software te forken. Overigens werden ook in andere ssl-implementaties vorig jaar kwetsbaarheden gevonden.

Reacties (51)

De overheid doet ook weleens dingen goed: Voordat OpenVPN goedgekeurd zou worden voor gebruik door de overheid moest eerst OpenSSL eruit gesloopt worden en vervangen worden door PolarSSL. Blijkbaar zag Fox-IT al dat de code niet helemaal lekker was.

nieuws: Overheid stapt over op opensource-vpn-pakket

Zelfs al was OpenSSL heel nette code, het blijft een goed idee om software modulair te bouwen en alternatieven mogelijk te maken. OpenVPN lostrekken van OpenSSL en er een alternatieve crypto engine in te zetten was een nog veel grotere uitdaging. Geheel toevallig was de keuze voor PolarSSL (nu mbedTLS) door Fox-IT niet, want men kent Paul Bakker (ontwikkelaar PolarSSL) wel.

Nu heeft OpenVPN zelf ook gewoon PolarSSL ondersteuning, zonder dat je de aparte OpenVPN-NL versie nodig hebt. Welke je moet gebruiken is aan jezelf, maar ik heb er een blog post aan gewijd een tijdje geleden vanuit het security oogpunt: 15 tips on OpenVPN security

Ik krijg onderhand het idee dat er meer gaten en lekken in OpenSSL zitten dan in een gemiddeld vergiet...

Dat wordt maar weer updaten dus. En dan maar duimen dat de ergste lekken nu opgelost zijn.

[Reactie gewijzigd door Zorian op 17 maart 2015 08:54]

Dat kan wel kloppen. Dat is ook een van de redenen waarom LibreSSL (wat een fork is van OpenSSL) is ontstaan.

OpenSSL heeft heel veel legacy code wat gewoonweg in de weg zit en wat voor de nodige problemen zorgt. Dat is ook een van de zaken wat LibreSSL eruit heeft gesloopt.

[Reactie gewijzigd door Typnix op 17 maart 2015 08:59]

Alsof "nieuwe" software meteen veel veiliger zou zijn. Dat is nog maar zeer de vraag. De oude software/code is veel meer getest en zijn al veel fouten en lekken uitgehaald. Nieuwe code is nog lang niet zoveel getest en moet zich nog bewijzen. Nieuwe software/code is daarom niet per definitie veiliger, de nieuwe lekken zijn simpelweg nog niet ontdekt...

Oude dus ook nog niet Nieuwe code betekent dat een frisse set ogen ernaar kijkt, met de kennis die we nu hebben over lekjes, buffer overruns en andere grappen. Verder betekent het dat het grootste deel in 1x geschreven is, en dan minder onbedoelde bij-effecten heeft (waarbij de auteur heel veel opties er half bijgehangen heeft, omdat het niet netjes kon). Minder code = minder bugs, ook

Code schrijven is makkelijker dan code lezen. Zegt niks over de frisse oogjes want wie is dat? En die code heeft zich nog niet bewezen. Wie weet wat daar nog aangehangen moet worden om het uberhaupt goed te krijgen. Alle eerdere kennis is weggeschoven en alle test uren aan de kant gegooid om helemaal overnieuw te beginnen. Als ontwikkelaar neig ik zelf ook eerder te denken dat je iets makkelijker opnieuw kan schrijven maar in de praktijk ligt het toch anders. Micro$oft heeft ook ooit eens een poging gedaan het office pakket lekker fris opnieuw te schrijven. Dat hebben ze vervolgens maar onder een tapijtje geschoven. Netscape is er bijvoorbeeld aan onderdoor gegaan.
Die buffer overruns moet je in de nieuwe frisse code ook allemaal nog weer zien te vinden in code waar verder niemand, behalve de frisse oogjes die het geschreven hebben, mee bekend is. Waarom zouden dat soort foutjes niet in nieuwe software zitten? Alleen omdat het nog niet gevonden is waarschijnlijk omdat er nog niemand goed genoeg mee bekend is. Klinkt als een schijnveiligheid.

Die buffer overruns moet je in de nieuwe frisse code ook allemaal nog weer zien te vinden in code waar verder niemand, behalve de frisse oogjes die het geschreven hebben, mee bekend is. Waarom zouden dat soort foutjes niet in nieuwe software zitten?

Omdat we tegenwoordig degelijke, goed doorgeteste en goed beveiligde data structuren en functies beschikbaar hebben in standaardbibliotheken specifiek geschreven met security-hardening in het achterhoofd. Zo krijg je niet het probleem wat OpenSSL had, waar één of andere druiloor maar besloten had om een eigen low level string copy functie te schrijven (met buffer overrun mogelijkheden er gratis bij), of een eigen memory allocator met use-after-free problemen (wat vziw ten grondslag lag aan Heartbleed).

[Reactie gewijzigd door R4gnax op 17 maart 2015 13:05]

LibreSSL is voor zover ik weet dan ook niet zozeer nieuw, het is een fork met daaroverheen een grote refactor & opruimactie van de code.

LibreSSL is OpenSSL - een hoop oude zooi die nodig is voor oude systemen die bijna niemand meer gebruikt. De organisaties en mensen die wel die oude systemen gebruiken (banken, verzekeraars, overheid met applicaties die alleen op die systemen draaien etc), die weten meestal wel hoe ze de boel moeten afschermen zodat ze alsnog veilig zijn, of ze zijn in staat de boel zelf te compileren.

Alsof "nieuwe" software meteen veel veiliger zou zijn. Dat is nog maar zeer de vraag. De oude software/code is veel meer getest en zijn al veel fouten en lekken uitgehaald. Nieuwe code is nog lang niet zoveel getest en moet zich nog bewijzen. Nieuwe software/code is daarom niet per definitie veiliger, de nieuwe lekken zijn simpelweg nog niet ontdekt...

LibrSSL haalt enorm veel code weg voor verouderder systemen, bv. MS-DOS-support, Win16-support, eigen malloc() functie om zwakke malloc()s te omzeilen, eigen random number generator om met slechte systeem-RNGs om te gaan en nog veel meer oude troep.

Ook wordt betere codeanalyse gedaan. Lees maar een de site van het project, staat veel op. Leuke is dat de hele site in Comis Sans MS geschreven is, met het argument "als je je daar aan stoort, dan moet je eerst maar de source code van OpenSSL lezen, dat is veel erger"

Omdat nIeuw niet betekend dat het massaal omarmt wordt. Veel bedrijven kiezen nu eenmaal voor OpenSSL omdat het eenmaal werkt met hun product of te huiverig zijn om een ander pakket te gebruiken omdat zij de materie botweg niet snappen.

Dat maakt een transitie lastig en blijven de problemen zich opstapelen zolang er geen echte acties wordt ondernomen door de bedrijven zelf maar ook door OpenSSL.

Ja, OpenSSL is geen groot project, maar wel essentieel voor een goed functioneren van internet. Zoiets moet voor de verandering eens echt degelijk en goed geregeld worden. Het valt me op dat het opnieuw https://en.wikipedia.org/wiki/Theo_de_Raadt moet zijn die het op de gepaste manier aanpakt.
Naar aanleiding van Heartbleed (de druppel die de emmer deed overlopen) zo snel mogelijk een fork LibreSSL.
Ik vind het bedenkelijk dat dit zo weinig aandacht krijgt, (vergeleken met smartwatches enz.) en ik ben bang dat dit komt omdat Theo de IT-mensen niet inspireert om ooit rijk en belangrijk te worden op een aantrekkelijke manier zoals halfgoden Gates en Jobs.
OpenSSL en de andere kwesties die voornamelijk en alleen door Theo en de zijnen worden aangepakt.. dat zegt mij wel wat: het nodeloos op de achtergrond raken van het 'algemeen belang'. En dat is een slechte zaak, vind ik.

[Reactie gewijzigd door Bas van Pelt op 17 maart 2015 09:42]

Het valt me op dat het opnieuw https://en.wikipedia.org/wiki/Theo_de_Raadt moet zijn die het op de gepaste manier aanpakt.

De gepaste manier? De gepaste manier zou zijn om openssl eens te gaan uitdunnen. Maar Theo doet wat hij altijd doet, een eigen projectje opzetten en daarna klagen dat andere devvers GPL licenties gebruiken.

Tuurlijk is aanpassen de eerste optie, maar Theo volgens mij legt goed uit waarom dat geen optie was voor OpenSSL. Andere opties zijn meer werk en daar zit Theo niet op te wachten, niemand toch? Het heeft een andere valide reden dat steeds iemand als Theo dan de consequentie trekt: het algemeen belang vereist het. Dat is los van een of andermans verdienmodel of zo. Kwesties zijn altijd gecompliceerd. Maar wat ik erover las was steeds: Theo stelt zich in mijn ogen onafhankelijk op en communiceert recht voor zijn raap. Ik waardeer dat. Eigenlijk best een bedreigende opstelling van hem voor een hele industrie. Hij maakt zo helaas weinig vrienden daar. Maar in het algemeen is het WEL een goede zaak. Ik denk dat het zeldzaam goed werk is wat hij doet. En dat de bijval daarvoor van een ruimere omgeving zou kunnen komen: van de belanghebbenden van veiligheid en privacy. Maar de aandacht van media en publiek gaat veel meer naar gemakzucht en fun-items. Met dit publiek kan de meerderheid van de IT-wereld gemakkelijk rotte eieren gooien naar hem, dat wel.

Bovendien hebben Apple en Google ook al OpenSSL opgegeven en gebruiken ook hun eigen fork. Dus kennelijk vonden ook die twee dat het goed mis was met de code en diens organisatie.

Ja, joh. Als je wilt dat je code overal gebruikt wordt, moet je juist GEEN GPL gebruiken, want dan zijn closed source projecten niet onder je userbase, en laat dat nog steeds het grootste aandeel software zijn.

Wat natuurlijk een totaal verkeerde aanpak is. Waarom proberen van een rotte appel iets lekkers te maken als er ook gewoon vers fruit voor het oprapen ligt.

Maar goed, ieder z'n keus natuurlijk. Bij elk OpenSSL lek glimlach ik en draai me nog eens lekker om.

Je kan het ook anders zien, ik las vanochtend nav dit lek een tweet waarbij iemand zei dat het pas echt eng word als er niet regelmatig dergelijke zaken naar buiten komen.
Dat kan namelijk betekenen dat er niet goed getest word, al dan niet door externe partijen. Na Heartbleed en Poodle zijn er veel meer ogen gericht op OpenSSL, wat goed is. Liever een paar mensen die met goede intenties dergelijke zaken ontdekken dan dat het in de doofpot zit (of geheel niet bekend) en dat kwaadwillenden de lekken misbruiken.

[Reactie gewijzigd door jozuf op 18 maart 2015 08:03]

Ik ben het opzich met je eens maar POODLE was volgens mij een lek in SSLv3 terwijl OpenSSL een implementatie van ssl/tls is . POODLE had je (volgens mij) niet gevonden door naar de OpenSSL te kijken.

[Reactie gewijzigd door Anoniem: 661369 op 17 maart 2015 17:23]

Je hebt gelijk, poodle heeft in principe niet direct met openssl te maken.
Er is ook niet echt een fix behalve sslv3 niet meer toestaan. En raakt zodoende alle implementaties, ook die van ms en Apple bv.
Je had het wel kunnen vinden door naar openssl te kijken, maar dat geld net zo goed voor ms en Apple of andere vendor (alhoewel je daar geen broncode van hebt). Het staat me bij dat het een manier was om de ssl verbinding encryptie te forceren om te downgraden naar sslv3 (mits zowel client als server dat toelaat/spreekt). Dat zou je uit de code kunnen destilleren. Ik zeg niet dat het zo ontdekt is overigens.
Wat volgens mij ook inhoud dat als er bv in tls1.0 een ernstig lek optreed (of beter gezegd een slimme truuk om het te kraken), poodle daar ook weer gebruik van kan maken. Oftewel config je webserver zodat het enkel veilige (relatief, want hè...) encryptie methode ondersteunt en je bent er van gevrijwaard.
Poodle is dan ook meer een zwakte van het protocol idd. En ook nodig voor legacy doeleinden.

Maar goed het is ms wat breder dan ik in eerste instantie stelde. Ms zijn er tegenwoordig meer mensen aan het kijken naar ssl/tls en de implementatie daar van. Wellicht dat je nsa zaken kan aanwijzen als mogelijke oorzaak om mensen ertoe te zetten zaken onder de loep te nemen.

[Reactie gewijzigd door jozuf op 17 maart 2015 18:01]

Naast de door anderen al gegeven redenen, besef ook dat sinds Heartbleed OpenSSL onder een vergrootglas ligt. De kans dat er dus problemen in de (complexe) code gevonden worden wordt daarmee groter.

En dat is een goede ontwikkeling, zo worden deze problemen nu opgelost terwijl ze voorheen niet eens onder de loep genomen werden.

Het probleem is dat deze stukken software vol met legacy code zitten. Het zelfde is met Java, Flash, etcetra. Deze code kan er niet zomaar uitgehaald worden omdat bijvoorbeeld oudere 'beveiligde' SSL verbindingen niet meer werken waardoor hele sites niet meer te bezichtigen zijn.

Het geluk is wel dat je tijdens het bouwen van je website software als Adobe Flash grotendeels kunt vervangen door HTML5 en Javascript deels door CSS3. Mijn Ubuntu machines hebben geen Flash of Java geïnstalleerd maar geven alle websites evengoed prima weer.

Echter zijn er veel legacy sites die nog steeds met deze oude zooi werken en nooit gëupdated zullen worden.

Sun Java deels door CSS3.

Java is een programmeertaal, zou het door JavaScript vervangen

JavaScript is ook een programmeertaal.
En het hele vergelijk met CSS3 slaat als een tang op een varken. Beiden dienen een wezenlijk ander doel.

Als je nog specifieker gaat kijken zijn Java en JavaScript script talen

Dat is met veel software het geval. Kijk maar naar Adobe Flash Player, Adobe Acrobat Reader en Sun JAVA. Stuk voor stuk softwarepakketten die op de meeste thuiscomputers zijn geïnstalleerd terwijl ze al sinds jaar en dag zo lek zijn als een mandje.

Lol, het probleem is dat OpenSSL open source is zonder deftig inkomen en dat zowat de hele wereld op het pakket steunt ... Dat er maar enkele kritieke lekken uitkomen betekend dat ze al veel moeite gedaan hebben om alles op orde te krijgen.

OpenSSL kost geen drol in verhouding met een goed en betrouwbaar SSL certificaat. En wat je vaak ziet is dat websites met name gaan voor de goedkope SSL, puur en louter om die SSL in beeld te krijgen of om een goed voetje bij de zoekmachine te behalen.

Eh, vergelijk je nou een ssl library(die ook voor €800 betrouwbare DV wildcards worden gebruikt) met de definitie van een CA?

Sowieso merkt de eindgebruiker geen verschil tussen een certificaat van € 10 en een certificaat van € 100, tenzij het een EV-certificaat is. Hoe dan ook slaat de redening van Jism als een tang op een varken...

Precies. Nooit uitgezocht maar verwacht eigenlijk zomaar dat er wellicht wat banken zijn die leunen op openssl, wellicht sommige internet bankieren sites?

Dus tsja, het is wijd verspreid en lang een ondergeschoven kindje geweest. Na recente incidenten is er weer volop geld in gepompt door bedrijven als MS (terwijl zij zelfs een eigen implementatie hebben)

[Reactie gewijzigd door jozuf op 17 maart 2015 18:06]

Voor meer info over heartbleed vorig jaar: http://www.heartbleed.nl/

Mocht men nog steeds getroffen zijn, schaam je.
Je hebt al een half jaar de kans gehad om te patchen, en nóg heb je dat niet gedaan!

Denk je dat mijn ouders überhaupt weten wat deze heartbleed is?? Die komen niet verder dan een ziekte. Laat staan dat ze dit dan op hun computers kunnen oplossen.

Het hoeft ook niet door je ouders opgelost te worden. Het is een server side issue en ook patch.

Er zijn enorm veel electronische toestellen, ik denk aan huis tuin en keuken routers, die OpenSSL gebruiken. Allemaal affected.

die apparatuur staat in de regel achter NAT waardoor de webinterface of een andere welke gebruik maakt van SSL/TLS niet benaderd kan worden vanaf het grote boze internet. Wanneer de PC/Laptop/Watdanook van je ouders gepwned wordt dan is het uitlezen van het het geheugen van een van die devices je minste zorg.

Heel vaak heeft die router een webinterface die niet achter NAT staat en een HTTPS webservertje heeft. Dus affected (hiervoor moet je nog wel wachten tot de eigenaar eens inlogged om dan zo het password te kunnen onderscheppen). Vaak kan je er ook op inloggen met bv. SSH, affected again (ik geloof remotely exploitable met root toegang in dat geval).

Waarom zou je dat willen doen? Misschien omdat soms het hele domotica-systeem van het huis inclusief het openen van garagepoorten en deuren achter dat routertje zit?

Er zijn wel wat reden te bedenken.

Dan heb je slimme ouders. Ze maken zich meer druk over ziektes waar ze wel wat aan kunnen doen, en een reeële bedreiging vormen, dan een obscuur lek waar ze verder ook niets mee kunnen. De berichtgeving rond lekken doet me steeds meer denken aan de opgeklopte Y2K berichtgeving. Er is wat aan de hand, ja, moet opgelost worden, ja, maar het risico wordt zwaar overdreven. Als we zo bang zijn voor lekken, waarom zijn er dan nog steeds lekkende kerncentrales en loopt niet de halve wereld Fukushima af te sluiten?

Of Chernobyl natuurlijk, die is ook nog steeds zo lek als een mandje. Maar die is intussen ook oud genoeg om "not my problem"-onzichtbaar te zijn. (Hitchhikers Guide to the Galaxy: boek 3).

De reden waarom is simpel: je kunt niet iets fixen waar je niet bij in de buurt kunt komen als mens zijnde. Wellicht over een paar decennia wanneer robots het werk kunnen doen.

De reden waarom is simpel: je kunt niet iets fixen waar je niet bij in de buurt kunt komen als mens zijnde. Wellicht over een paar decennia wanneer robots het werk kunnen doen

Tjernobyl is enige tijd na de ramp weer opgestart (minus de ontplofte reactor) en heeft tot 2000 geproduceerd. Ze zijn inmiddels al begonnen apperatuur te verwijderen van reactor 1.

Ook zijn ze bezig de sarcofaag die na de ramp om de ontplofte reactor is gebouwd te vervangen voor een nieuwe. Dat is allemaal mensen werk. Welliswaar geld er een keiharde wet voor mensen dat ze na iedere 5 dagen werken op locatie 15 dagen off-site vakantie moeten hebben vanwege de verhoogde straling, maar het is niet meer zo ernstig als in de eerste dagen na de ramp, toen de robots die het dak op werden gestuurd binnen enkele minuten compleet doorgebrand waren door de intense straling.

Kort blik op de code:
Changes
===
Changes between 1.0.2 and 1.0.2a [xx XXX xxxx]

*) Removed the export ciphers from the DEFAULT ciphers
[Kurt Roeckx]]
===

Export ciphers zijn:
===
The cipher suites with "EXPORT" are, by design, weak. They are encrypted, but only with keys small enough to be cracked with even amateur hardware (say, a basic home PC -- symmetric encryption relying on 40-bit keys). These suites were defined to comply with the US export rules on cryptographic systems, rules which were quite strict before 2000
===

Als dus standaard de export ciphers worden meegenomen dan wordt er standaard de mogelijkheid tot een 40-bit key gegeven. Lijkt wel erg sterk op het TLS Freak-lek wat vorige week door diverse platformen gedicht is.

Dat is op de 1.0.2 branch, die nog niet zoveel mensen gebruiken. En, iedereen weet dat je geen export ciphers aan moet zetten, maar zelf je cipher suites moet instellen. Volg bijvoorbeeld de Mozilla wiki.

Veel interessanter zijn de commits in de stable repo. Ga los en speculeer erop los. Zo te zien is er al heel wat gepusht in de repo namelijk. Voor de 1.0.1 branch vanaf de laatste stable:
https://github.com/openss...1l...OpenSSL_1_0_1-stable

Check public key is not NULL.

CVE-2015-0288
PR#3708

Fix a failure to NULL a pointer freed on error.

Inspired by BoringSSL commit 517073cd4b by Eric Roman <[e-mail]>

CVE-2015-0209

[Reactie gewijzigd door gertvdijk op 17 maart 2015 11:47]

Ik blijf me altijd een beetje verbazen over de hoeveelheid kritiek die losbarst bij een software update of patch.
Patches en updates zijn juist goed, daarmee worden bestaande problemen verholpen.
Software waar nooit een patch of update voor uitkomt is pas echt verdacht.

Even inhakend op de je laatste zin, het duurde best wel lang voordat de eerste patch voor OpenSSL er was. En het was gelijk voor een grote en triviale bug. Dus OpenSSL is daarmee inderdaad verdacht. Wat komt er nog meer boven tafel.... En dan ontstaat er inderdaad een collectieve verontwaardiging, omdat we er wel op vertrouwd hebben. Uiteraard wijzen de meesten naar een ander wiens schuld het is. Zo is de mens nu eenmaal. Ik verbaas me er net over, het is voorspelbaar.

Er wordt gesproken over severity "High". Dacht dat daarboven nog een niveau "Critical" zit.
Dus het zou mee kunnen vallen. Ook is het onduidelijk of het om client-side of server-side vulnerabilities gaat.

Volgens https://www.security.nl/p...voor+OpenSSL+aangekondigd is de kritieke lek alleen in 1.02, 1.01 ook wel problemen maar met minder impact.

Het meest kritieke lek bleek alleen in 1.02 te zitten en valt redelijk mee. Alleen DoS mogelijk
https://openssl.org/news/secadv_20150319.txt

Ze nemen het open wel erg serieus