OpenSSL verhelpt kritiek lek dat ontstond door recente patch

OpenSSL heeft een patch uitgebracht voor een kritiek lek dat er mogelijk voor kan zorgen dat een aanvaller op afstand code kan uitvoeren. De kwetsbaarheid werd volgens het OpenSSL-team geïntroduceerd door een recente patch.

OpenSSL heeft maandag in een security advisory laten weten dat de kwetsbaarheid alleen voorkomt in versie 1.1.0a van de software. Daarom zouden gebruikers die de update nog niet hebben uitgevoerd meteen van versie 1.1.0 naar 1.1.0b moeten updaten. Het lek, met kenmerk cve-2016-6309, treedt op doordat de software een buffer verplaatst als er een bericht van meer dan 16k wordt ontvangen. In de vrijgemaakte ruimte zou vervolgens een aanvaller met een achtergebleven pointer kunnen schrijven. Dit zou kunnen leiden tot het uitvoeren van willekeurige code.

Het OpenSSL-team had vorige week een patch uitgebracht voor een lek dat het op afstand uitvoeren van code mogelijk maakte. Deze kwetsbaarheid werd door het team ingeschat als een variant met 'hoog' risico. Het door de patch geïntroduceerde lek is daarentegen aangemerkt als 'kritiek'. Dit is de ernstigste categorie. Het team zegt het bericht zonder de gebruikelijke voorafgaande notificatie uitgebracht te hebben vanwege de ernst ervan. OpenSSL heeft Robert Święcki van Googles beveiligingsteam genoemd als de ontdekker van het lek.

Reacties (35)

Dit gebeurt wel irritant vaak bij OpenSSL. Zijn er nauwelijks contributors die de commits checken ofzo?

Het heeft meerdere redenen:

• Cryptografie is best ingewikkeld dus het vinden van contributors is lastig. Kleine sidenote: het helpt niet dat protocollen als TLS ook niet altijd even logisch in elkaar zitten, gelukkig zal TLS 1.3 hier verbetering in brengen zodat er minder kans is voor het implementeren van fouten.
• Tot en met Heartbleed was de code en leiding van het project rommelig te noemen. Veel legacy code mbt geheugenmanagement bijvoorbeeld. Dit was reden voor nieuws: OpenBSD-ontwikkelaars maken OpenSSL-fork (hier hun terugblik). Google heeft voor hun eigen gebruik een fork genaamd BoringSSL. Gelukkig is het OpenSSL-project zelf ook aan het moderniseren, maar code review gebeurt pas sinds vorig jaar(!).
• Je kan dan de ontwikkelaars van OpenSSL een stel prutsers vinden, maar dat zijn grotendeels vrijwilligers want pas na Heartbleed is er echt geld beschikbaar gekomen voor onderhoud: nieuws: Linux-stichting en grote tech-bedrijven willen OpenSSL-beveiliging op... en nieuws: Open encryptieprojecten krijgen half miljoen euro van Nederlandse ove...

For better or for worse: Heartbleed heeft de wereld wel wakker geschud. Maar een project uit december 1998 moderniseren kost nou eenmaal tijd.

[Reactie gewijzigd door Rafe op 26 september 2016 16:09]

Het feit dat OpenSSL in C is geprogrammeerd met eigen allocatie en de-allocatie van geheugen is zeker ook een probleem. Geheugen access in C is niet "managed". Dat wil zeggen dat als er problemen zijn dat ze ook meteen gebruikt kunnen worden voor buffer overrun attacks and wat al niet meer gevonden kan worden.

Ik hoopte ooit dat dit met statische code analyse (symbolic execution etc.) gevonden zou kunnen worden in unmanaged talen zoals C, maar dat is ijdele hoop gebleken. De eigen geheugen allocatie code zou hierbij wel eens een negatieve rol kunnen spelen (dit wordt waarschijnlijk niet opgepikt door statische tools).

Feit is dat dit met managed talen (array boundary checking, garbage collection) nooit voor kan komen. Niet dat daar geen nadelen aan zitten of dat er helemaal geen problemen kunnen ontstaan. Maar remote code execution na zo'n onbenullige bug is uiterst onwaarschijnlijk.

Verder is OpenSSL qua code gewoon een puinhoop te noemen. Het is nog niet zo erg als NSS (waar laatst een bug in zat die nog erger was, in de ASN.1 decoding routines) maar een rommeltje is het wel. Leesbaarheid& *is.in C toch --al _niet z[0] hoog, dan gaat code style veel uitmaken bij het maken van fixes zoals deze.

- manual allocatie is een risico voor lang lopen, (agv memory leaks), maar niet voor veiligheid.
- Bounds checken is geen exclusief gebied van managed talen.

Het probleem van managed talen , nog afhankelijk van verhoogd CPU en memory gebruik , is dat de VM de attack surface alleen nog maar verhoogd.

Waar dat toe leidt zien we in de maandelijkse patch rondes. Java, .NET en Adobe Flash.

Manuele allocatie is wel degelijk een probleem in C, omdat C met pointers werkt. Als je software security by Coursera volgt dan schrik je al snel hoe makkelijk daar een zootje van de maken is.

Ik heb inderdaad me er wat makkelijk vanaf gemaakt door bounds checking een onderdeel van managed talen te maken. Het is wel zo dat Java en C# het wel hebben en C zeer zeker niet.

Het aantal problemen met de VM is relatief klein te noemen. De reden voor de grote hoeveelheid patches is vooral de enorme hoeveelheid functionaliteit die Java met zich meeneemt. Dit is inclusief interessant spul zoals browser plugins, webstart, class managers.

Verder bevat Java ook een complete TLS implementatie. Dat wordt bij C als separate bibliotheek geteld. Zo is het natuurlijk lastig vergelijken. Hopelijk wordt dit met Java 9 iets duidelijker, als de runtime in stukjes wordt gehakt.

Wel is het update proces gewoon slecht te noemen. Niemand zit te wachten op weer een eigen update manager die dan ook nog eens een hele JRE gaat downloaden. Dat irriteert zelfs mij als Java developer mateloos.

Er zijn niet managed talen die niet voor de bulk van hun features op pointers berusten en checks hebben. Sterker nog die bestonden al VOOR C.

C heeft problemen, maar dan direct naar Java/C# gaan (die OOK een bron van een zeer significant deel van de software beveiligings problemen zijn!) is het kind met het badwater weggooien, en stapt volkomen over de problemen van die talen heen. (en dan met name de inmense attack surface van hun runtimes) heen.

[Reactie gewijzigd door marcovtjetje op 29 september 2016 07:49]

Erg interessant dat verhaal van LibreSSL! Open-source is ook maar houdbaar tot een bepaald niveau, dan ga je meer overzicht nodig hebben.

Open source is houdbaar op ieder niveau, ontwikkelen met alleen vrijwilligers niet.

dan ga je meer overzicht nodig hebben

Dat heb je over het algemeen sneller bij open source dan bij closed source hoor. Je hebt 0,0 overzicht bij gesloten code.

Kan je pakketten genoeg aanwijzen die closed source zijn, dik geld kosten en absolute bagger zijn. Zelfs spul in het bedrijfsleven wat door de leveranciers nog als courant wordt omschreven maar in VB6 geschreven is of nog op FoxPro draait e.d. Closed source kan aanzienlijk erger zijn, je wordt er alleen niet zo snel op geattendeerd...

Ik zeg niet dat het prutsers zijn maar ze moeten wel de ernst begrijpen van hun werk. Als de halve wereld zowat op jouw encryptie software draait dan geeft dat een bepaalde verantwoordelijkheid. Dan kan je niet zoals bij HeartBleed op vrijdagavond nog even iets er in hacken en daarna nooit meer naar kijken. Dat is gewoon onverantwoord.

Het is een kritiek stukje software, dus het ligt constant onder een vergrootglas. Er zullen vast meer bugs zitten in andere programma's die je gebruikt, maar die zijn niet zo altijd zo kritisch.

Alleen checken is niet genoeg. Je hebt het hier over een complex stuk software. En er moet ook maar net iemand iets opvallen of er moet een test zijn die zoiets afvangt. en vergeet ook niet dat men snel patches wil. Je hebt geen weken om dit te testen, wat je bij andere software misschien wel hebt.

Maar als je vind dat ze het niet goed doen: ze willen vast wel versterking.

[Reactie gewijzigd door gjmi op 26 september 2016 15:20]

Ik heb helemaal geen tijd om ze te versterken vanwege de tig andere FOSS projecten waar ik m'n tijd al aan besteed; en als ik het wel had: ik denk juist dat een probleem is dat er teveel cooks in the kitchen komen die niet voldoende verstand hebben van het coden voor een project als OpenSSL... Daar krijg je sloppy code van en dingen die over het hoofd gezien worden omdat er geen rekening wordt gehouden met andere variabelen. Ik zou ze best willen helpen, maar zal soms juist in de weg lopen; en dat moet je voorkomen... Ik zou willen dat meer mensen op o.a. GitHub dat doen Maar goed, ik die geen tijd heb is geen excuus voor hen om dan maar sloppy troep af te leveren.

Maar dat je geen weken zou hebben om te controleren omdat men snel patches wilt, dat is natuurlijk volstrekte onzin. Ja, men wil graag snel patches. Nee, dan wacht men maar lekker ff een dagje langer! Wat wil je nou liever? Een geteste en gecontroleerde patch, of een afgeraffeld stuk bocht waardoor je dit soort fratsen krijgt? En dat is niet de eerste keer bij OpenSSL, en dat vergrootglas is eigenlijk ook geen terecht excuus... Als mensen snel patches willen die niet tot nauwelijks getest zijn, breng dan lekker een nightly dev build uit ofzo. Maar om nou eigenlijk alpha/beta fixes te pushen naar alle servers, puur omdat een stel mensen zitten te stressen om een onmiddelijke patch...? Dan moeten DIE mensen die onmiddelijke patches eisen maar gaan contributen...

Ja het is complexe en belangrijke software, en juist daarom is het controleren van de committed code zo uitermate belangrijk. Ik vind het dus geen excuus, maar juist een reden waarom het veel beter getest had moeten worden.

[Reactie gewijzigd door WhatsappHack op 26 september 2016 15:47]

Ja, het is belangrijk dat je goed de tijd neemt om te testen. Maar aan de andere kant moet er ook snel een patch komen om schade door het lek te voorkomen.

Niet dat dit een verdediging is. Ik zie alleen dat het vaak een moeilijke afweging is.

Ja, het is belangrijk dat je goed de tijd neemt om te testen. Maar aan de andere kant moet er ook snel een patch komen om schade door het lek te voorkomen.

Er zat geen enkele critical fix in de update van afgelopen donderdag. High severity mag maximaal een maand zonder release blijven:
https://www.openssl.org/policies/secpolicy.html

Er was dus wel een beetje haast, maar niet overdreven veel. Maar die high severity fixes zorgden er wel voor dat de fix private moest blijven en dat er geen externe review op de patches gedaan kon worden.

[Reactie gewijzigd door Jan-E op 26 september 2016 17:22]

Het is niet code testen dat helpt dit soort bugs te vinden. Dit soort bugs vinden doe je met verstand en mensen werk. WhatsappHack kan zijn expertise (zover die rekt) ook leveren aan OpenSSL om potentiele probleem vectoren in de code al aan te duiden.

Normaal wel, maar deze bug werd geïntroduceerd door een wijziging om een veel onbenullerige bug te fixen. Dat riekt toch wel naar het niet goed controleren van wat er nou eigenlijk gecommit was naar de code toe, en checken wat je wijziging doet en welke implicaties dat heeft.
Misschien komt dat wel omdat ze te snel hebben released om dat vorige lek te patchen, maar als haast dit veroorzaakt: dan moeten ze toch eens goed nadenken of een paar extra controles met een kleine vertraging niet veiliger zijn dan een snelle patch met grote risico's... Ik heb liever een paar uur of een dag langer geen patch, dan een patch die een veel gevaarlijker probleem veroorzaakt. Foutjes kunnen, maar dit is redelijk bizar.

Zoals ik al zei heb ik zelf geen tijd om te contributen aan OpenSSL, dat is dus ook geen tijd voor audits.

Vergeet ook niet dat er veel kritiek is op de OpenSSL code vanuit niet de minste ontwikkelaars:

Het Heartbleed-lek in de OpenSSL-programmeerbibliotheek is volgens veel softwareontwikkelaars mede het gevolg van onleesbare en complexe code, en slechte documentatie vanuit de OpenSSL-ontwikkelgemeenschap. De ontwikkelaars achter de LibreSSL-fork spreken dan ook over een 'zeer slechte codebase' en zeggen de code flink te gaan opschonen.

nieuws: OpenBSD-ontwikkelaars maken OpenSSL-fork

Ik zelf vind OpenSSL een draak om mee te werken. Voor mij als ontwikkelaar is mbedtls velen malen makkelijker.

Vergeet ook even niet, dat openBSD zijn stroom rekening niet kon betalen en met zijn LibreSSL en comic sans, openBSD weer wat ruimte gegeven heeft.

Idd, top ontwikkelaar


Je kan ook zeggen, grotere bedrijven hebben jaren gratis en voor niets gebruik gemaakt van openssl, zonder er ook maar iets in resources voor terug te geven.

Er zijn ondertussen al een paar openssl forks, juist omdat er teveel issues in openssl ontdekt worden. Er zijn dus redelijk wat mensen die vinden dat openssl de boel niet goed onder controle heeft.

En hebben die geld en resources en kennis om dit soort problemen te voorkomen? LibreSSL is natuurlijk een goed alternatief, maar voor de rest is het maar afwachten of je beter uit bent.

Die forks nemen dus de bestaande problemen in eerste instantie mee.....

Want de hele handel van scratch af aan opnieuw bouwen is een probleem.

security/cryptografie is zo een ongelooflijk complex geheel dat het aantal mensen dat aan dit soort projecten kan en wil meewerken zeer beperkt is.

Absoluut, het is niet bepaald slechts een scriptje om je koffieautomaat een seintje mee te geven; maar uiterst complex en cryptografisch geavanceerd.

Aan de andere kant zijn er tig vrijwilligers met die kennis én mensen bij grote organisaties die hun devs richting OpenSSL sturen (aldanniet eens in de zoveel tijd) om te contributen. Dat is een luxe die maar heel weinig OS producten hebben... Maar als je kijkt naar de problemen van dit en vorig jaar, dan merk je daar weinig van.

De vraag is hoe dat komt, en dat is misschien niet de complexiteit; ik heb eerder t vermoeden dat t misschien aan t team zelf/maintainers ligt.
Maar dat kan ik mis hebben.

Mi heb je weinig security-achtergrond nodig om desbetreffende bug te vermijden?

Ik ben het deels met je eens, maar niet volledig. Cryptografie is erg moeilijk vanwege de mathematiek en de standaarden die letterlijk over-engineered zijn.

Echter hebben we hier te maken met prutserij. Stap 1 bij het uitvogelen van een bug of vulnerability is 'wat veroorzaakt het / hoe wordt het geactiveerd'. In veel gevallen is dit probleem niet van wiskundige aard, noch van de overgroeide standaarden, maar simpel een gevalletje slechte code waar een beetje coder zich voor zou schamen.

Afgaande op het artikel klinkt het alsof er weer geprutst is met buffers. Een beetje sprayen en overflowen, een paar NOP treintjes en geassocieerde shellcode, en de aanvallers hebben weer kassa. Natuurlijk wordt het gepruts in de hand gewerkt door de slechte staat van de code, maar juist dan zoek je nog beter uit hoe het in elkaar zit omdat je refactoren in het achterhoofd hebt. ZEKER bij een project zoals dit!

Ik zou het trouwens geweldig vinden als deze 'remote executie vulnerability' letterlijk de mathematiek en algoritmes zelf om zeep had geholpen door een omissie van iets dat krapweg in 1 zinnetje wordt gedefinieerd in een of andere standard paper. Als op die manier de deur wijd open wordt gezet heeft OpenSSL tenminste een degelijk excuus.

Security fixes worden niet eerst publiek gemaakt voor ze gereleased worden, dus er zijn minder mensen die mee kunnen kijken of er problemen inzitten. Meer mensen uitnodigen om er naar te kijken levert weer meer risico op... lastig om de grens te bepalen.

Het feit dat ze een patch leveren voor DDOS die daardoor een nog ernstigere RME vul heeft geeft aan dat ze dit toch op z'n minst zouden moeten overwegen.

Dit probleem is namelijk zo goed als direct aan het licht gekomen. Anders hadden ze er niet nu al een patch voor.

Of false contributors?

Ik vind het ook knullig dat een patch voor een lek een nog groter lek creëert. Doet me ernstig twijfelen over de competentie van de ontwikkelaars bij OpenSSL.

Veel distro's hangen nog op de 1.0 branch, dus je zal hier niet per se last van hebben. (Voor zover je het runnen van een update commando al lastig vind.)

Voor 1.0.2 is er ook een issue en moet ook worden bijgewerkt naar een nieuwere versie:

Missing CRL sanity check (CVE-2016-7052)
========================================

Severity: Moderate

This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016.

A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0
but was omitted from OpenSSL 1.0.2i. As a result any attempt to use
CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.

OpenSSL 1.0.2i users should upgrade to 1.0.2j

The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and
Thomas Jakobi. The fix was developed by Matt Caswell of the OpenSSL development
team.

https://www.openssl.org/news/secadv/20160926.txt

Dus niet de complete 1.0 branch is vrijgewaard van recente bugs.

[Reactie gewijzigd door MegaTronics op 26 september 2016 17:03]

Ik heb nu versie 1.01t op mijn server. Is deze veilig?

Ja, alleen 1.1.0a is niet veilig. Jij zit op een oudere release (1.0.1t) waar deze fout niet in zit. Mogelijk wel weer andere fouten, maar dat weet je pas als je de CVE's bekijkt die op de versies tussen 0.1t en 1.0a betrekking hebben.

Die is veilig, het gaat alleen om de nieuwste versie 1.1.0 en dan de a patch er van.
Die 1.1.0 is vrij nieuw dus het is niet onlogisch dat distributies even wachten voordat ze daar op over stappen.

Bedankt. Hoef ik me daar niet druk om te maken.