LibreSSL kampt met geheugenlek en bufferoverflow-kwetsbaarheid

Beveiligingsonderzoekers van Qualys hebben twee kwetsbaarheden in LibreSSL gevonden. De opensource implementatie van het ssl-protocol kampt met een geheugenlek en een bufferoverflow-kwetsbaarheid in een functie. In OpenBSD zijn ze waarschijnlijk niet te misbruiken.

Qualys was op zoek naar mogelijkheden om op afstand code uit te voeren via recent ontdekte lekken in OpenSmtpd, schrijft het bedrijf. OpenSmtpd is een smtp-daemon die door het OpenBSD-team is ontwikkeld met hoge beveiliging en goede prestaties als belangrijkste doelen.

Mogelijkheden voor remote code execution werden niet gevonden maar bij het zoeken ernaar, stuitte het bedrijf wel op een geheugenlek in de OBJ_obj2txt()-functie van LibreSSL. Deze opensource implementatie van het ssl-protocol maakt gebruik van OpenSmtpd. Met behulp van de kwetsbaarheden kunnen aanvallers systemen laten crashen en mogelijk code uitvoeren.

De kwetsbaarheden bevinden zich in alle versies van LibreSSL. De ontwikkelaars werken aan een oplossing. OpenSSL is niet getroffen en ook zijn de kwetsbaarheden waarschijnlijk niet in OpenBSD uit te buiten, schrijven de ontdekkers. LibreSSL is een fork van OpenSSL, die ontstond nadat met de Heartbleed-bug een ernstige kwetsbaarheid in de code van OpenSSL bekend werd. Naast OpenBSD maakt bijvoorbeeld OpenELEC gebruik van LibreSSL.

Reacties (37)

Mogelijkheden voor remote code execution werden niet gevonden maar bij het zoeken ernaar, stuitte het bedrijf wel op een geheugenlek in de OBJ_obj2txt()-functie van LibreSSL. Deze opensource implementatie van het ssl-protocol maakt gebruik van OpenSmptd. Met behulp van de kwetsbaarheden kunnen aanvallers systemen laten crashen en mogelijk code uitvoeren.

Volgens mij maakt OpenSMTPD gebruik van LibreSSL en niet andersom. Wat moet een SSL library met SMTP?

Overigens willen de ontwikkelaars van OpenSMTPD later overschakelen naar libtls volgens dit bericht. Waar de overschakeling van OpenSSL naar LibreSSL redelijk zacht is (beide zijn tot een zekere hoogte compatible met elkaar), zal de overschakeling naar libtls (een nieuwe programmeerinterface van LibreSSL) een stuk intensiever zijn en compatibiliteit met OpenSSL breken. Op de lange termijn moet het wel een stuk simpeler worden, doordat de nieuwe interface makkelijker schijnt te zijn in gebruik.

[Reactie gewijzigd door The Zep Man op 19 oktober 2015 11:22]

Dat denk ik ook, ik was mij al aan het afvragen waarvoor smpt juist stond in de context van SSL (blijkt dit een typo te zijn in het artikel)

De server administrator op de hoogte brengen of er gehackt wordt wellicht...

De issues zijn in LibreSSL 2.2.4, 2.1.8 en 2.0.6 al opgelost op de dag dat de CVE's publiek gemaakt zijn.

Bron: http://www.libressl.org/releases.html

[Reactie gewijzigd door Tremere op 19 oktober 2015 11:10]

Het risico van forken natuurlijk. Men maakt ene fork omdat het origineel als niet veilig genoeg word aanzien en introduceert bij het herschrijven van delen van de code natuurlijk nieuwe bugs die, mede doordat er zo weinig mensen naar die code kijken, langer blijven zitten.

Het risico van forken natuurlijk. Men maakt ene fork omdat het origineel als niet veilig genoeg word aanzien en introduceert bij het herschrijven van delen van de code natuurlijk nieuwe bugs ...

Tot zover helemaal mee eens.

die, mede doordat er zo weinig mensen naar die code kijken, langer blijven zitten.

Dat zie ik graag onderbouwd. Voor zover ik weet waren er ondanks de enorme populariteit van OpenSSL juist veel minder mensen die naar de code keken dan verwacht. Volgende de LibreSSL developers is dat o.a. omdat de code bijzonder slecht leesbaar was [1]. Er werden verschillende stijlen door elkaar heen gebruikt. Oude code of weinig gebruikte code wordt niet verwijderd [2], ook vandaag de dag laat men ongeteste code zitten [3]. Daarnaast werd er te weinig nagedacht of nieuwe functies die bepaalde bedrijven wilden, wel secure was te bouwen en niet het geheel zou ondermijnen (Heartbleed). Als klap op de vuurpijl gebruikte men een eigen geheugen management engine waardoor de extra beveiligingen die OpenBSD heeft, en die deze bug in LibreSSL nu ook mitigeert, omzeilt werden [4].

[1] http://www.openbsd.org/pa...14-libressl/mgp00008.html
[2] http://www.openbsd.org/pa...14-libressl/mgp00013.html
[3] http://marc.info/?l=openb...ech&m=144472550016118&w=2
[4] http://www.openbsd.org/pa...14-libressl/mgp00007.html

En wat doe je als je gaat forken? Denk je dat er dan ineens meer mensen naar de geforkte versie gaan kijken dan naar het origineel? Of zou het misschien kunnen dat die mensen die wel de code bekeken zich ineens gaan splitsten in de twee kampen en dat er daardoor minder aandacht zal gaan naar elks van die projecten dan dat er vroeger naar het origineel ging?

Oude code bleef inderdaad zitten en dat resulteert automatisch in verschillende stijlen omdat men vandaag anders denkt over hoe men goede code moet schrijven dan 20 jaar terug. Dat men oude code laat zitten komt ook omdat men de achterwaartse compatibiliteit wil behouden. Bijkomend is de kans dat in de oude code nog grote fouten zitten statistisch gezien een stuk kleiner net omdat er al zoveel over gekeken is geweest en zoveel mee getest is geweest. Een statistisch kleine kans wil uiteraard nog niet zeggen dat het niet mogelijk is.

En het is leuk dat LibreSSL nu op OpenBSD geen last heeft van het geheugenlek dat toch echt in het project zit. Maar wat als ik LibreSSL op Linux zou zetten? Het lijkt mij dat dat geheugenlek dan toch wel een rol zal gaan beginnen spelen. Extra beveiliging in 1 OS betekend nog niet dat je fouten in een multi platform library zomaar mag gaan goedpraten.

Denk je dat er dan ineens meer mensen naar de geforkte versie gaan kijken dan naar het origineel? Of zou het misschien kunnen dat die mensen die wel de code bekeken zich ineens gaan splitsten in de twee kampen en dat er daardoor minder aandacht zal gaan naar elks van die projecten dan dat er vroeger naar het origineel ging?

Niet ineens, maar als een project wel leesbaar is, minder code bevat en een uniforme moderne programmeerstijl gebruikt dan zal dat hopelijk op den duur resulteren in meer ogen per lijn code.

Het lijkt mij dat dat geheugenlek dan toch wel een rol zal gaan beginnen spelen. Extra beveiliging in 1 OS betekend nog niet dat je fouten in een multi platform library zomaar mag gaan goedpraten.

Eens, het is zeker een fuckup.

Het zou overigens helpen als TLS zelf ook niet zo verschrikkelijk ingewikkeld was geweest*.

* https://news.ycombinator.com/item?id=10411663

Naast dat er nog meer versies zijn die eigenlijk niets toevoegen aan de originele, denk dan dus gewoon van, fix de problemen in het origineel en ga daar verder mee..

Waarom is zo'n SSL library schrijven moeilijk?

Omdat TLS heel complex is, zie RFC 2246, 4346 en 5246 en deze discussie: https://news.ycombinator.com/item?id=10411613. Uit deze thread:

ASN.1 is complex - people still make mistakes in the DER parsers as seen in this CVE. X509 is even more complex - it's not just ASN.1. It can be DER in DER in DER (parameters of certificate extensions). Have fun with that and memory ownership! (you have to recalculate and replace an object 2 levels above what you're actually changing) TLS is even worse, because it includes X509 as a format and then a ton more of actual processing logic, state machines, cryptography code, ...

De complexiteit van SSL/TLS en daarbij horende X.509 en ASN.1 is een van de redenen waarom bijv. OpenSSH er geen gebruik van maakt en eigen encryptie protocollen gebruikt en een eigen simpeler certificaat formaat heeft bedacht:

The SSH protocol currently supports a simple public key authentication
mechanism. Unlike other public key implementations, SSH eschews the use
of X.509 certificates and uses raw keys. This approach has some benefits
relating to simplicity of configuration and minimisation of attack
surface, but it does not support the important use-cases of centrally
managed, passwordless authentication and centrally certified host keys.

These protocol extensions build on the simple public key authentication
system already in SSH to allow certificate-based authentication. The
certificates used are not traditional X.509 certificates, with numerous
options and complex encoding rules, but something rather more minimal: a
key, some identity information and usage options that have been signed
with some other trusted key.

http://cvsweb.openbsd.org...9&content-type=text/plain

[Reactie gewijzigd door SlaSauS op 19 oktober 2015 18:13]

Waarom schrijft men in het artikel tot 3x toe: SMPT ?? Het is toch SMTP ? Het zal vast geen tikfout zijn als het 3x is gebeurd maar ik kan geen informatie vinden over SMPT.

• Qualys was op zoek naar mogelijkheden om op afstand code uit te voeren via recent ontdekte lekken in OpenSmptd
• OpenSmptd is een smtp-daemon die door het OpenBSD-team is ontwikkeld met hoge beveiliging en goede prestaties als belangrijkste doelen.
• Deze opensource implementatie van het ssl-protocol maakt gebruik van OpenSmptd.

edit:
Lijst met voorbeelden toegevoegd

[Reactie gewijzigd door Jael_Jablabla op 19 oktober 2015 11:52]

Dergelijke opmerkingen horen niet onder het artikel maar in dit topic: Spel- en tikfoutjes - en dus *geen* andere foutjes

Daar kunnen deze vervolgens urenlang genegeerd worden

[Reactie gewijzigd door Spider.007 op 19 oktober 2015 15:48]

Dergelijke opmerkingen horen niet onder het artikel maar in dit topic: Spel- en tikfoutjes - en dus *geen* andere foutjes

Dat is alleen bedoeld voor "spel- en tikfouttjes - en dus geen andere foutjes". Aangezien het hier om 3x dezelfde spelling gaat, mag ik toch wel aannemen dat er geen sprake is van een tikfout (en dus hoort het niet in dat topic thuis), maar om nieuwe technologie waar ik niet bekend mee ben. Nu begrijp ik van jou dus dat het gaat om een tikfout.

Fappant dat OpenBSD dan zelf weer niet vatbaar is, ondanks dat de lek en kwetsbaarheid voorkomt in software voor en door OpenBSD.

Pijnlijk is het wel, want er is net een nieuwe versie van OpenBSD uit en LibreSSL is juist geforked van OpenSSL met als doel om veiliger te zijn dan OpenSSL.

[Reactie gewijzigd door RoestVrijStaal op 19 oktober 2015 11:07]

OpenBSD heeft een aantal maatregelen waardoor het moeilijker wordt om een lek te misbruiken, bijvoorbeeld dat de kernel na het booten op slot gaat, en dat door willeurige wijzigingen iedere keer dat een programma loopt, extra checks om de stack van een programma te beschermen, e.d. Vermoedelijk is het daarom niet doenlijk het lek in OpenBSD te misbruiken, maar dat bewijzen is een stuk lastiger. Het lek is echter wel degelijk in OpenBSD aanwezig en hun beveiligingsmensen zullen wel degelijk aan het werk moeten.

Waarom wordt zo'n geheugenlek niet gevonden bij het ontwikkelen van de library, of in ieder geval bij het vrijgeven van een nieuwe release? Valgrind zou zo'n lek toch moeten vinden?

Valgrind zou zo'n lek toch moeten vinden?

Alleen als je een codepad aanroept wat een geheugenprobleem veroorzaakt.
Dit probleem zal niet in een pad van 'normaal' gebruik zitten, anders zou het wel gevonden zijn...
Echter, hackers houden zich niet echt aan 'normaal' gebruik...

Was het idee van LibreSSL niet dat het veiliger zou zijn dan OpenSSL?

Nee hoor, Theo de Raadt had wat geld nodig om de stroom rekening te betalen om netopenBSD in de lucht te houden. En het kwam hem goed uit dat openssl in eens na jaren van te weinig geld zoveel beveiliging gaten heeft.

LibreSSL heeft namelijk in 1 a 2 weken tijd meer geld opgehaalt dan heel openssl in de jaren er voor, ondanks openssl door heel veel grote jongens gebruikt wordt.

[Reactie gewijzigd door wica op 19 oktober 2015 11:14]

Troll much? Waarom gebruikt Apple nu dan LibreSSL in OS X en heeft Google een eigen fork van OpenSSL? Omdat OpenBSD niet veel funding heeft? De fork van OpenBSD lijkt haar doel te bereiken: veel minder advisories dan voor OpenSSL.

Nog een recente anecdote: http://thread.gmane.org/gmane.os.openbsd.tech/44816

Nee hoor geen troll, vondt het alleen opvallend hoe Theo de Raadt toen in eens met LibreSSL aankwam en zijn gal over openssl heen storte, met daarbijkijk eens hoe goed wij zijn.

En waarom gebruikt Apple nu LibreSSL? En waarom moest google zijn Fork maken?
Als alleen al deze 2 bedrijven,maar ook een Cisco wat meer resources en/of geld gestoken hadden in openssl. Welke door iedereen werdt gebruikt. Was heel Internet een stuk veiliger.

De LibreSSL fork is vooral te danken aan Ted Unangst. Zie hier meer over de historie: http://www.tedunangst.com/flak/post/origins-of-libressl

En waarom gebruikt Apple nu LibreSSL? En waarom moest google zijn Fork maken?
Als alleen al deze 2 bedrijven,maar ook een Cisco wat meer resources en/of geld gestoken hadden in openssl. Welke door iedereen werdt gebruikt. Was heel Internet een stuk veiliger.

Op een gegeven moment moet je gewoon een project afschrijven omdat het te ver heen is.

Je kan niet steeds door blijven bouwen op bagger, eens moet je ook eens aan de fundering gaan sleutelen.

De reden dat ze niet op OpenBSD zijn te exploiten is omdat OpenBSD allerlei extra beveiligingen in het OS heeft gebouwd wat de beveiliging van alle applicaties die je erop draait ten goede komt. In dit geval was het ProPolice wat de gevonden bugs mitigeert. Qualsys heeft er het volgende over te zeggen:

However, when triggered through X509_NAME_oneline() (and therefore d2i_X509()), this buffer overflow is stack-based and probably not exploitable on OpenBSD x86, where it appears to always smash the stack canary.

Het is goed dat er gezocht wordt naar beveiligingsproblemen. Maar dat "beveiligings"-bedrijven hier publiciteit mee proberen te genereren is een vrij irritante trend aan het worden. Submit een patch en klaar zou je denken, het is niet voor niets open-souce...

Ik vind het een prima ontwikkeling. Als beveiligingsbedrijven hiermee de publiciteit krijgen die ze willen, hebben ze dus ook een grotere reden om naar beveiligingsproblemen te zoeken.

Hulde dus aan beveiligingsbedrijven die lekken vinden in open source software. Op dat meer bedrijven daar energie in zullen steken!

Dat ben ik gedeeltelijk met je eens, maar het ondermijnt wel het werk dat door andere vrijwilligers uitgevoerd wordt: het werk dat er voor zorgt dat deze libraries uberhaupt beschikbaar zijn.

Hoe ondermijnt het precies hun werk? Ik zou eerder zeggen dat het hen ondersteunt. Door de hulp van dit externe bedrijf wordt een fout gevonden die ze zelf nog niet hadden gevonden. Dat is toch juist top?

Ik ben mee met de voordelen, die zijn er absoluut. Het is een goede zaak dat fouten gevonden worden en vervolgens opgelost kunnen worden, beter dan dat ze op de zwarte markt eindigen.

Het aspect waar ik naar verwijs is het volgende. Ik heb er een dubbel gevoel bij dat er voor het toevoegen van functionaliteit in proportie minder erkenning te verkrijgen lijkt. Wachten tot iemand een foutje maakt (overdrijving) en die repareren is daarbij schijnbaar genoeg om het van de daken te roepen. Het (gewoon) repareren van de bug en een patch submitten is bij dit soort projecten naar mijn mening meer op zijn plaats.

Verder staat LibreSSL alsnog vrij om te communiceren met zijn gebruikers dat er een belangrijke security-fix beschikbaar is.

[Reactie gewijzigd door Nelis123 op 19 oktober 2015 14:29]

Het aspect waar ik naar verwijs is het volgende. Ik heb er een dubbel gevoel bij dat er voor het toevoegen van functionaliteit in proportie minder erkenning te verkrijgen lijkt. Wachten tot iemand een foutje maakt (overdrijving) en die repareren is daarbij schijnbaar genoeg om het van de daken te roepen. Het (gewoon) repareren van de bug en een patch submitten is bij dit soort projecten naar mijn mening meer op zijn plaats.

Ik zou zeggen, vind de bugs en patch ze voor de commerciële bedrijven en jij hebt je zin.

Het is gewoon een kwestie van first-come first-serve.
En blijkbaar wil niemand er net zoveel / meer werk insteken dan de commerciële bedrijven.

Het is goed dat hier aandacht aan komt, zo weten gebruikers ook dat ze kwetsbaar zijn en moeten updaten. Als je de boel stilletjes patcht maar iedereen gebruikt nog steeds oudere builds dan ben je net zo ver van huis.

Omdat totdat die patch verwerkt is in een release is het belangrijk dat systeembeheerders weten dat deze lekken bestaan zodat zij alsnog maatregelen kunnen nemen om misbruik tegen te gaan.