OpenSSL dicht kwetsbaarheid die denial of service-aanval mogelijk maakt

OpenSSL heeft patches uitgebracht voor een lek dat misbruikt kan worden om een denial of service-aanval uit te voeren op kwetsbare servers. De ernst van het lek wordt ingeschat in de categorie 'hoog'. OpenSSL dicht daarnaast dertien minder ernstige lekken.

OpenSSL schrijft dat de kwetsbaarheid het kenmerk cve-2016-6304 heeft ontvangen en aanwezig is in verschillende versies van de software. Het team raadt gebruikers aan om een update uit te voeren naar versies 1.1.0a, 1.0.2i of 1.0.1u, afhankelijk van de aanwezige versie. Het lek maakt het voor een aanvaller mogelijk om via een grote OCSP status request extension het geheugen van een server te laten vollopen. Dit kan hij teweeg brengen door steeds opnieuw een verzoek te verzenden. Hierdoor kan de server vastlopen of opnieuw opstarten, schrijft Akamai.

Servers met een standaardconfiguratie zijn kwetsbaar voor een dergelijke aanval, ook als zij ondersteuning voor OCSP uit hebben staan. Servers die met de 'no-ocsp'-optie zijn ingericht of die gebruikmaken van een standaardconfiguratie met versie 1.0.1g of lager zijn niet getroffen. Servers in de laatste categorie zijn alleen kwetsbaar als een applicatie OCSP stapling support inschakelt.

OpenSSL had de patches voor het door het Chinese bedrijf Qihoo 360 ontdekte lek eerder deze week al aangekondigd. De software wordt gebruikt om beveiligde verbindingen tot stand te brengen en vormt een implementatie van ssl en tls.

Reacties (38)

De ernst van het lek wordt ingeschat in de categorie 'hoog'.

Beetje rare categorie, je zou verwachten dat binnen de categorie beschikbaarheid zou zijn en vervolgens deze kwetsbaarheid een bepaalde ernst heeft (in dit geval hoog). Zo zou je de categorie en de ernst veel beter en duidelijker kunnen weergeven met BIV factoren (beschikbaarheid integriteit vertrouwelijkheid) met vervolgens de ernst of te wel de impact*kans=risico/ernst inzichtelijk te maken.

Nu is het net alsof alsof je een dashboard hebt met 1 rode lamp, je weet niet of je moet tanken of dat je olie op is....

maar dat is mijn mening maar

naast high hebben ze ook critical, moderate en low.
Dus je hebt wel iets meer lampjes of multicolor. :-)

Verder heb je Common Vulnerability Scoring System (CVSS) (https://www.first.org/cvss) dat wordt bij sommige CVE's er wel bijgezet. Dat gaat zelfs een stuk verder dan je BIV: https://www.first.org/cvss/calculator/3.0

Heb je inderdaad een stuk meer aan.

Het probleem is met je voorbeeld is dat de fabrikant niet kan zien wat er op jouw dashboard configureert is. Daarbij geven ze toch aan met grote lijnen waar het risico zit ?

Wat je zegt klopt, zij kunnen niet inkijken op jouw configuratie. Echter kunnen ze wel aangeven op welk vlak een kwetsbaarheid zich manifesteert.

Door het in BIV factoren te weergeven kan je allicht een richting geven binnen de maatwerk configuratie op locatie. als voorbeeld beschikbaarheid geeft aan dat ik in naar de volgende instellingen moet kijken-->toegangsprotocollen-->OCSP instellingen

Want nu is het net alsof je met spoed moet updaten terwijl je het "maar" een beschikbaarheidsprobleem is.

Maar zoals ik zei het is maar een idee, ik snap dat deze generieke manier van categoriseren makkelijk is maar allicht iets te kort door de bocht.

De categorisering is inderdaad niet fantastisch maar er zijn in iedergeval verschillende niveaus. Het is gewoon lastig te voorspellen of zo'n BIV verwachtingen die OpenSSL maakt zou houden als je gaat kijken hoe verschillend OpenSSL als library wordt ingezet.

In dit geval lijkt het vooral om een beschikbaarheidsprobleem te gaan maar Akamai geeft de duiding dat het ook tot crashes kan leiden van de 'HTTP server'. (Met hoe dat geschreven is vraag ik me dus af of dat dan de HTTP daemon is of dus echt het hele gast OS, maargoed.)

De vraag is dan hoe andere applicaties in die server zich gedragen in low memory situaties en mogelijke crashes, en hoe goed je server is in booten. (Een nadeel van systemen die altijd up zijn is bijvoorbeeld dat je soms niet goed test of ze nog wel zelfstandig kunnen booten... oeps) Hoe belangerijk is die dienst op je server, en draaien niet bijna al je servers met verschillende belangerijke diensten OpenSSL? Dat geeft dus al snel een andere invuling aan die BIV categorisatie in verder verglijkbare situaties.

In dit geval gaf OpenSSL dit 'hoog' omdat het met de standaard config exploiteerbaar was ook al gebruikte je geen OCSP functies, alleen het expliciet uitzetten met no-ocsp hielp kennelijk maar daar denk je misschien niet zo snel aan bij het inrichten van je platform want 'het werk al' met de default config. Wat dat dan voor impact heeft op de afnemende systemen is lastig te overzien.

Wat betreft de severity levels betreft hanteert OpenSSL vier niveaus zijnde Low, Moderate, High en Critical. Die laatste is er trouwens nog maar recent bijgekomen, en voor meer uitleg daarover, zie https://www.openssl.org/b.../critical-security-level/

Hoe lang duurt het gemiddeld tot zo'n update is verwerkt in de repo van Ubuntu Server?

Even een wget op de source doen (https://www.openssl.org/source/openssl-1.0.1u.tar.gz), uitpakken (tar zxf openssl-1.0.1u.tar.gz) en builden (cd naar openssl-1.0.1u, type ./configure en type daarna make install). Is bij mij altijd goed gegaan op Ubuntu en Centos.

[Reactie gewijzigd door j-phone op 22 september 2016 15:21]

Dat is een bijzonder slecht idee. `make install` installeert namelijk in /usr/local en krijgt voorrang op de OpenSSL die via je package management hebt geinstalleerd. In de toekomst kan je dus voortaan *altijd* je systeem handmatig gaan updaten zo, omdat toekomstige package updates een schijnupdate zijn geworden dan.

In plaats daarvan, build lokaal een Debian/Ubuntu/CentOS package met de patches en installeer die.

[Reactie gewijzigd door gertvdijk op 22 september 2016 15:36]

Repositories van de grotere distro's willen nogal eens achterlopen met openssl releases. En zolang je weet / communiceert dat openssl op die manier is geinstalleerd zie ik geen probleem.

Als het je privéservertje is, prima. In een omgeving waarin meerdere mensen het systeem beheren ofwel gaan beheren in de toekomst heb je anders zojuist een recipe for disaster geschreven. En laat nou net productieomgevingen de belangrijkste/urgenste systemen zijn om te patchen nu. Vandaar mijn -1 in de context van dit nieuws.

Zelf een build maken is een goed idee als je distro achterloopt inderdaad, daar ben ik het mee eens. Echter, je moet wel je package management op de hoogte stellen ervan. Een blinde `make install` is bijna altijd een slecht idee met de consequenties die ik al schetste. (Tenzij je zelf aan het project ontwikkelt of het in een throw-away omgeving gooit zoals een Docker container.)

Over het algemeen ontwikkel en beheer ik inderdaad solo. Binnen grotere teams (met eigen Linux beheerders) zal het via package management wel beter zijn. Maar voor mensen zoals ik is het geen probleem (en ik ken er wel meer die zo werken, maar die weten gewoon waar ze mee bezig zijn;).

de meeste distributies werken hun repos op enkele uren tijd bij. Het is niet omdat het versienummer achter loopt dat de veiligheid niet op orde wordt gehouden. Debian zal security fixes gewoon backporten bijvoorbeeld naar de versie die zij op dat moment ondersteunen.

Daarentegen wordt de impact van een update wel getest tegen de overige software van het ecosysteem aan, in elk geval bij RHEL. Die zijn overigens altijd behoorlijk vlot met uitbrengen van dit soort fixes, soms in de vorm van de daadwerkelijke nieuwe versie soms wordt de fix gebackport aangezien de volledige nieuwe versie teveel impact kan hebben op de rest van het ecosysteem.

Duurt het te lang of wil je software die er niet is, creeer je eigen repo, evt zelfs gecombineerd met een build system zoals Jenkins.

vergeet vooral niet van tevoren te checken of de checksum klopt, zorg dat je de ubuntu patches van ubuntu eroverheen gooit, en zorg dat al je andere libs, headers en je compiler up to date zijn. Verder zou ik ooi geen make install doen, maar er een .deb van bouwen en die installeren. Ook niet vergeten de oorspronkelijke package te verwijderen, en alle software die libssl laadt te herstarten.

Persoonlijk zou ik dit soort dingen _nooit_ source installen op productieservers, but that's just me. Als je eenmaal begint in het handmatig installeren, dan moet je het daarna dus altijd handmatig blijven doen, en dat is echt niet een schaalbare oplossing.

Ik vind het dus niet een heel goed advies Maar goed, zoveel mensen, zoveel wensen natuurlijk

Haha, als jij het geen probleem vindt dat:
- de source misschien aangepast is (want checksum niet gecheckt)
- je patches van je distro mist
- andere software niet getest is met je nieuwe library
- draaiende services niet herstart worden, en dus nog kwetsbaar zijn
- je dependency management stuk is (want je gaat buiten je package manager om)
- je geen automatische updates meer krijgt
- je een complete buildomgeving op je productie server hebt
- je meerdere versies van dezelfde library door elkaar krijgt (standaard source install zal naar /usr/local/ gaan, ipv /usr)

Dan is het wel OK. Voor de rest van de wereld is dit denk ik niet OK

Ik heb altijd wel respect voor mensen die zelf hun bibliotheken bijhouden en niet vies zijn van een eigen build. Dat het niet voor iedereen is weggelegd en dat package management alles een stuk complexiteit wegneemt betekend niet dat zelf compilen niet kan in een distributie, je moet dat dan wel bewust zelf bijhouden.

Linux from scratch is dan ook een fantastisch project om zelf te leren hoe alles aan elkaar hangt.

OpenSSL is dan wel niet een beginners bibliotheek, omdat hij heel diep ingrijpt op veel andere pakketten.

Ik heb altijd wel respect voor mensen die zelf hun bibliotheken bijhouden en niet vies zijn van een eigen build.

Let even op dat de post van borft gaat over productieservers, terwijl het klinkt alsof jij het veel meer hebt over je eigen bak thuis. Dat maakt een wereld van verschil.

Zelf builden is niks mis mee maar niet op de productie servers zelf, build packages op een apart systeem met alle development libraries en tools (die wil je gewoon niet op een productieserver hebben) en stop die packages in een eigen repo. Dan heb je dependencies opgelost en als het belangrijk voor je is test je het ook tegen de andere software die je draait voor het in productie gaat.

Juist op een productie webserver moet je dit soort dingen niet flikken.

In plaats van "make install" zou ik "checkinstall" aanraden trouwens. Op die manier kan je met je package manager alles ongedaan maken. Maar zoiets als openssl op een productieserver vanuit source installeren moet je gewoon niet doen. Dan vraag je er echt om en ik ben er vrij zeker van dat het reden voor ontslag kan zijn wanneer het misgaat.

Mwa, er was al Linux voordat de distro's en package managers er waren toch?

Mwah, de eerste release van Debian is meer dan 20 jaar geleden. Als dat je reden voor een source install is, moet je echt even onder je steen vandaan komen

Natuurlijk is een package managed install niet de enige manier, maar het is wel een beetje industry best practice!

En natuurlijk mag je helemaal zelf weten hoe je het doet op je eigen machines

FYI: zowel Ubuntu als Debian hebben inmiddels een update gereleased:
- ubuntu: http://www.ubuntu.com/usn/usn-3087-1/
- debian: https://security-tracker.debian.org/tracker/CVE-2016-6304

[Reactie gewijzigd door borft op 23 september 2016 08:50]

Als Debian het gefixed heeft, gaat het snel voor Ubuntu:
https://security-tracker....er/source-package/openssl

Nog niet blijkbaar, opmerkelijk, meestal komt men naar buiten als de patches uitgerold zijn. Bug is op 29 aug gemeld.

Ondertussen is Jessie wel gefixed.

Is dat niet irrelevant, je kunt toch buiten de repo om updaten? Naar mijn weten is er geen protocol voor de snelheid van het opnemen van nieuwe updates binnen de repo.

Dat geeft soms wat complicaties, waarbij het beter is om te wachten op de package managers.

Is meestal binnen 6 tot 24 uur na patch gefixed.

Is dat niet irrelevant, je kunt toch buiten de repo om updaten?

Als je een enigszins redelijk onderhoudbaar systeem wilt niet.

Is het nuttig om deze update af te wachten voor het maken van een certificaat. Op de officiële website staat die al vermeld, maar ik gebruik de naar windows geportte versie. Ik heb gisteren V1.1.0 gedownload vanaf http://slproweb.com/products/Win32OpenSSL.html, hoe snel zou er een nieuwe versie uitkomen en is het zinvol om te wachten voor mijn doel, of maakt dat niets uit in deze update?

Nee, gewoon certificaat aanmaken. Het is een DoS vector, de Vertrouwelijkheid loopt geen gevaar. Wel aangenomen dat je huidige/toekomstige HTTPS configuratie up-to-par is; imho minimaal een A- op ssllabs.com (al zegt A+ ook niet alles).

Offtopic: Kan niet wachten op TLS 1.3 (Voordelen hier) . Mogelijk wordt het zelfs TLS 2.0, net zoals HTTP/2. Eindelijk 'open crypto' ipv van het 15+ jaar oude NIST/NSA algoritme-monopolie.

[Reactie gewijzigd door SKiLLa op 22 september 2016 21:11]

Bedankt, dus ik ga gewoon in de huidige versie een ca maken.

Hoe zorg je eigenlijk voor een A(+) op www.ssllaps.com, je mag ook in mijn eigen topic reageren.

offtopic:
Zie mijn topic beveiliging Qnap nas vanaf buiten voor meer informatie over de reden van het certificaat.

[Reactie gewijzigd door T.Kreeftmeijer op 22 september 2016 21:22]

Heel simpel: geef de juiste cipher suits op, Zorg dat alle suites FS aan hebben staan/ondersteunen. Zet ssl dicht (tls 1.2 en 1.0 aan). Zet hsts header, zet https-only modes aan.

En kies een goed certificaat zonder links met de juiste lange sterke sleutel.

Dan haal je met ssllabs.com een A+.

Kijk dan ook of je http/2 aan kunt zetten op je server. En of je alle door OWASP geadviseerde security headers kunt zetten. CORS moet géén * zijn.

Kijk of je een csp-reporting urls kunt inrichten.

Info:
https://github.com/ssllab...Deployment-Best-Practices
https://www.owasp.org/ind...aders_Project#tab=Headers
http://www.html5rocks.com/en/tutorials/cors/
http://www.html5rocks.com.../content-security-policy/
https://bjornjohansen.no/enable-http2-on-nginx

Tool om snel je config op orde te krijgen:
https://mozilla.github.io...tls/ssl-config-generator/

Zorg dat je webserver versie en je openssl versie op to date zijn, kies dan modern. En kijk in ssllabs of de browsers die je wilt ondersteunen nog ondersteunt worden.


Test voor http/2 https://tools.keycdn.com/http2-test zorg dat ook ALPN ondersteunt wordt.

En last but not least maak ook deze tests groen: https://securityheaders.io

https://www.ssllabs.com/ssltest/

OT:
Als dat op orde is maak dan ook deze groen: https://gtmetrix.com

[Reactie gewijzigd door djwice op 22 september 2016 22:17]

Ik ga het rustig bekijken en als ik nog een vraag heb stuur ik je een berichtje, dat is handiger dan hierin te reageren.

Hoe relevant is deze lek voor mij?

Ik draai sinds kort een Apache2 webserver op een Raspberry Pi 2B, waarbij ik gebruik maak van letsencrypt certificates. Nu zal niemand mijn site targeten omdat er weinig te halen/te blokkeren valt, maar moet ik hier iets mee? Het klinkt vrij serieus en zo ja, waar kan ik meer vinden over hoe ik dit kan patchen?

In het geval van een Denail Of Service exploint zal een Pi wel tegenvallen als doelwit maar een hoop dingen op het internet zijn 'niet slim genoeg' om te weten dat je geen doelwit bent, een simpele worm probeert gewoon elk systeem waarvan ie hoopt dat t kwetsbaar is.

De kwetsbaarheid die hier besproken wordt is niet zo interessant voor je Pi, veel van de andere bugs zijn ook DOS door middel van geheugen vasthouden per connectie of geheugen lekken. Er zijn echter ook een paar buffer overflows en een foutje waarbij iemand mogelijk een DSA sleutel kan stelen, wat waarschijnlijk niet van toepassing is op jou server.

Als je Pi gewoon Raspbian draait met een standaard Apache package is het beste wat je nu kan doen iets van sudo apt-get update en dan sudo apt-get upgrade in het terminal. Het probleem is dat de package maintainer van het Raspbian OpenSSL package misschien een beetje achterloopt, dit was namelijk ook iets wat mensen dwarszat toen Heartbleed was aangekondigt.