OpenSSL patcht ernstige bufferoverflow-kwetsbaarheid

Het OpenSSL Project heeft een patch uitgebracht voor een ernstige kwetsbaarheid in OpenSSL 3.0. Versie 3.0.7 repareert twee kwetsbaarheden die bufferoverflows kunnen veroorzaken. Het gebeurt zelden dat OpenSSL een dergelijke grote patch uitbrengt.

Het OpenSSL Project kondigde vorige week al aan dat het met een patch zou komen voor een bug. Daarover wilden de softwaremakers toen nog niet veel kwijt, vermoedelijk omdat ze vermoedden dat aanvallers zich konden klaarmaken voor uitbuiting als er meer details bekend werden. Inmiddels is die informatie wel naar buiten gekomen. In de releasenotes van OpenSSL 3.0.7 staat dat er twee kwetsbaarheden zijn gerepareerd: CVE-2022-3786 en CVE-2022-2602. Die lijken beide nog niet in de Mitre-database voor kwetsbaarheden te zijn opgenomen.

De releasenotes van OpenSSL 3.0.7 beschrijven dat er twee bufferoverflows zijn gerepareerd in de software. Die kunnen beide worden getriggerd via de verificatie van X.509-certificaten, maar hoe dat precies werkt, beschrijft OpenSSL niet. Wel zeggen de makers dat de kwetsbaarheden een gespooft certificaat vereisen.

Het OpenSSL Project schrijft dat aanvallers op twee manieren een bufferoverflow kunnen triggeren. Dat kan door een e-mailadres aan te maken met daarin een bepaald aantal bytes waarin een '.' voorkomt, wat een denial of service kan veroorzaken. In een TLS-client kan dit getriggerd worden door verbinding te maken met een schadelijke server, zo schrijft OpenSSL. Bij TLS-servers kan een bufferoverflow veroorzaakt worden als deze clientautorisatie aanvragen en een schadelijke client vervolgens verbinding maakt.

Met de tweede kwetsbaarheid kan een aanvaller ook een soortgelijke bufferoverflow veroorzaken met een e-mailadres, maar door die kwetsbaarheid zou in theorie ook op afstand code uitgevoerd kunnen worden. Er zijn volgens OpenSSL wel verschillende mitigerende factoren. Daardoor is de ernstigheidsscore van die tweede kwetsbaarheid teruggeschroefd naar 'high', waar deze eerst als 'critical' werd aangemerkt.

Beveiligingsexperts keken al een week uit naar meer details over de kwetsbaarheid. Onder andere het Nederlands Nationaal Cyber Security Centrum plaatste een waarschuwing. Het komt niet vaak voor dat OpenSSL dergelijke grote updates uitbrengt, specifiek als het om beveiligingslekken gaat.

Reacties (35)

[Pixelmagic]

Misschien ook de moeite waard om te vermelden dat de versie 1.1x geen risico heeft, deze word nog met erg veel versies van Linux standaard geleverd. Mijn Debian versies zijn b.v. allemaal zonder dit risico.

[LanTao]

De impact is inderdaad nogal beperkt. Vrijwel niemand gebruikt de 3.0 branch, eigenlijk alleen Fedora en Ubuntu 22.04.

[meowmofo]

Dat is ook wel weer een beetje te kort door de bocht.

Zie de lijst van NCSC https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software

[JasperM]

Vrijwel alle laatste versies van de Linux distro’s zijn kwetsbaar.
En vergeet een groot aantal (Docker) container images ook niet.
Zie: https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software

Overigens is de kwetsbaarheid een beetje een anti-climax en ook afgeschaald naar high.

[gekkie]

Ja gelukkig was dat al gecommuniceerd dus zag ik relatief weinig impact voor mijn spul behalve op m'n laptop die relatief wat op de troepen vooruit loopt.

[Jeoh]

Heel veel bombarie over de tweede critical vulnerability ooit, en dan krijgen we deze natte scheet. Jammer dat ze niet eerder hebben aangekondigd dat ze 'm hebben gedowngrade naar high, dat had een hoop mensen een hoop tijd gescheeld.

[CAPSLOCK2000]

Het is inderdaad zeer onhandig maar toch beter zo dan andersom.

Wat me misschien nog wel het meeste dwars zit is dat we met z'n allen nu zo iets hebben van "Oh, het zijn maar 2 high vulnerabilities, ik hoef niks te doen...", terwijl er toch nog steeds 2 high vulnerabilities zijn gevonden in een enorm belangrijk stuk software, het is nog steeds best wel riskant.

We hebben het geluk dat deze versie van openssl nog niet zo veel gebruikt wordt. Aangezien de bugs mogelijk misbruikt kunnen worden met een gek e-mail-adres zie ik eindeloos veel plekken die kwetsbaar kunnen. E-mail-adressen worden overal en nergens gebruikt en ook verwerkt op talloze backend systemen die niet direct bereikbaar zijn via internet.

[curry684]

Sorry maar nee, deze vulnerabilities stel ik al vraagtekens bij of ze wel high hadden moeten zijn. Het zijn denial of service mogelijkheden waarvoor je een CA-signed cert moet hebben in een situatie waar de cliënt zich ermee authenticeert, oftewel een vulnerable client met een malicious server. Dit heeft simpelweg op het overgrote deel van het publieke internet nul komma nul impact en was daarmee alle heisa en vooral de vooraankondiging niet waard - dit gaat niet het halve internet slopen zoals Heartbleed. Nog afgezien van het feit dat het publieke internet amper OpenSSL 3 gebruikt.

Het hele circus van afgelopen week is als een weeralarm van het KNMI, niemand luistert er nog naar omdat ze bij een stevig windje al op alle radio's te horen zijn. Dat is stom en het grootste beveiligingsprobleem van dit soort communicatie: de uitholling van het waarschuwingsmechanisme waardoor systeembeheerders bij de volgende echte Heartbleed minder paraat staan om snel te acteren.

[dok33]

waardoor systeembeheerders bij de volgende echte Heartbleed minder paraat staan om snel te acteren.

Misschien is dit wel 4D chess door de aanvallers... Onbelangrijke kwetsbaarheden vinden en brengen alsof ze belangrijk zijn, om dan later toe te slaan en gen reactie te krijgen...

[Transportman]

Helaas herkenbaar, ik heb genoeg klanten gezien waar LCM echt onderaan het lijstje staat en nooit budget voor is, maar aan de andere kant beheerders en teamhoofden de volledige organisatie in paniek brengen als er een CVE in onze software gevonden wordt, omdat toevallig een dependency van een dependency van een dependency een CVE heeft voor functionaliteit waar wij geen gebruik van maken maar die wel bij een security scan op het systeem waar onze software draait gevonden is. Maar onze software wel weer een slechte naam omdat we een CVE hebben, wij weer aan iedereen uit moeten leggen dat er toch niets urgents aan de hand is maar dat we wel nieuwe versie klaar hebben staan waarin de dependency bijgewerkt is naar een versie waar de CVE niet in zit, maar die wordt vervolgens weer niet uitgerold bij de klant want geen budget.

[Blokker_1999]

Het zijn twee bugs waarvan de eerste toch echt op kritiek is blijven staan. En ook een bug met hoge ernst is er 1 die je liefst zo snel mogelijk ziet verdwijnen.

[meowmofo]

Zeker niet. Ze zijn beide een high.

[curry684]

Nee de eerste was al high omdat er geen remote code execution mogelijk was.

Het is inderdaad een natte scheet uiteindelijk, beide vulnerabilities zijn amper exploitable in de echte wereld.

[meowmofo]

Ik ben ook echt goed pissig om de manier waarop dit is gegaan. Er zitten hier een hele hoop mensen klaar om actie te nemen, mensen die allerlei belangrijke andere zaken moesten pauzeren om dit aan te pakken, en dan dit. Ik snap echt niet hoe ze de inschatting zo onwijs verkeerd hebben kunnen doen. Deze wijze van werken levert zo veel schade op. Ze zien me hier al aankomen de volgende keer met een pre-announcement van een critical vulnerability.....

[supersnathan94]

ohw oke, want? Ik zit hier niet zo diep in, maar wat is er precies mis gegaan in de gang van zaken waardoor dit zo'n zure nasmaak achterlaat?

[meowmofo]

Omdat het gecommuniceerd werd als critical. Bij een vorige critical vulnerability in OpenSSL was het halve internet lek. De impact was echt enorm. Nu bij het uiteindelijk uitbrengen van de patch blijkt het enkel een high te zijn en is de impact veel lager.
De wereld zat klaar voor de impact zoals gecommuniceerd. Heel veel mensen zijn heel wat tijd kwijt geweest voor voorbereidingen. Hier liggen plannen klaar om de public facing services down te brengen en daarmee de bedrijfsvoering stil te leggen.

[Reactie gewijzigd door meowmofo op 30 juli 2024 09:34]

[curry684]

Er werd de indruk gewekt dat dit verhaal vergelijkbaar was met Heartbleed, een vulnerability waar binnen 24 uur de eerste proof of concept exploits al van rond gingen en waarbij kritieke informatie ontvreemd kon worden tot complete serverovernames.

Dus ja, bij zo'n vooraankondiging staan veel profi systeembeheerders standby. Ik heb zelf m'n sportavond vanavond verzet in volle verwachting dat ik er uren werk aan zou kunnen hebben. Vervolgens krijgen we 2 moeilijk exploitable DoS gaatjes.

Ken je dat verhaal van Peter en de wolf?

[Soldaatje]

Bedoel je niet 'De jongen die wolf riep', van een van de fabels van Aesopus?

[curry684]

Uh ja goed punt, dank voor de correctie

[johnny2000]

Vind het een beetje flauw antwoord. Dit gaat hier om een opensource project en jij loopt allemaal eisen te stellen?

Ze hadden dit zelf eerst op critical gezet, maar ander partijen hebben aangegeven dat het dusdanig lastig te misbruiken is dat ze de impact hebben verlaagd.

Openssl is een beetje de voetenveeg van het internet. Iedereen gebruikt het, en bijna geen funding en altijd maar zeuren.

[Reactie gewijzigd door johnny2000 op 30 juli 2024 09:34]

[WhatsappHack]

De funding is grotendeels gefixt via het core infrastructure initiative, maar verder wel eens met je betoog.

[Tom Paris]

Ze hebben nagelaten om te communiceren 'bij nader inzien schalen we af van critical naar high, meer details volgen' vanuit verwachtingsmanagement.

[curry684]

Bekend verhaal ja, ik heb meerdere klanten vooraf geïnformeerd over mogelijke downtime overdag, want ja kritiek probleem. Zit je vervolgens met dit verhaal waarvan ik me al een kwartier zit af te vragen of ik er überhaupt ook maar IETS aan hoef te doen.

[Rolfie]

Het lijkt inderdaad wel een blunder te zijn. Ik ken menig persoon dat nu standby stond om actie te ondernemen.

Maar als ik het nu zie, valt het inderdaad wel mee. Nog steeds security updates die je snel wilt installeren, maar het heeft niet de impact die de wereld er van had verwacht.

Ergens een communicatie foutje?

[Frame164]

Ze zijn, zoals ze zelf aangeven, altijd op zoek naar mensen die willen helpen. https://www.openssl.org/community/getting-started.html

[c-nan]

De aankondiging van OpenSSL vorige week was misschien overtrokken, maar dat is jou reactie ook. Het was al bekend dat het enkel om versie 3.x ging. Zo heel veel draait er nog niet op versie 3.x.

Om hier een heel team klaar voor hebben staan en allerlei belangrijke zaken moet pauzeren gaat ook erg ver. Je kon ook je public facing devices met OpenSSL 3.x downgraden.

Wat heb je allemaal draaien wat vulnerable is?

[RoestVrijStaal]

Opvallend dat de forks LibreSSL en BoringSSL er geen last van hebben.

Hoog tijd om die eens een kans te geven.

[Frame164]

BoringSSL = Google. Grote kans dat die er opeens weer mee stoppen gezien hun historie. En dan ben je verder van huis dan een keer een bug in een stabieler product.

[Rolfie]

Als ik de informatie er over lees, is die niet echt geschikt voor groot gebruik. Veel te specifiek ontworpen om gebruikt te worden door Google infrastructuur. Maar het kan natuurlijk wel, maar "hoog tijd om die een kans te geven", is eigenlijk niet haalbaar aangezien het een behoorlijke impact heeft.

BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

[Verwijderd]

Belangrijke use-case voor boringSSL is de TLS fingerprinting omzeilen van Cloudflare, aangezien deze denkt dat je een Chromium engine bent.

[_JGC_]

Dat is niet zo vreemd. Beide zijn geforkt van OpenSSL toen Heartbleed bekend werd. Toen zaten we nog ergens op 1.0.x. Er zijn hele stukken code van OpenSSL herschreven of verwijderd in die forks, die gaan echt geen 3.x code backporten.

Deze bug is geintroduceerd in nieuwe 3.0 code en was niet aanwezig in 1.x.

[Rolfie]

Want daar kunnen nooit security issues inzitten?
Wie zegt dat daar ook niet zulke of misschien nog grotere security issues in zitten, die we gewoon nog niet weten?

OpenSSL 3, is nog betrekkelijk nieuw, OpenSSL 1.1.1 was ook niet vatbaar voor deze security issues, waarbij de meeste leveranciers deze 1.1.1 versie ook gebruiken.

Maar dit was een hoop paniek voor eigenlijk niets. Ja er moet geupdate worden, maar het was niet zo kritiek dat het hele Internet in gevaar is/was.

[Nilltris]

Wie net als mij even aan het zoeken was naar hoe je OpenSSL kan updaten:

Edit: of het de beste manier is weet ik niet!

Linux:

• Log in op je server, mogelijk heb je root rechten nodig
• Maak een tijdelijke directory aan en ga binnen de directory (mkdir /opt/openssl en cd /opt/openssl bijvoorbeeld)[/i]
• Haal de update binnen vanuit openssl.org (wget https://www.openssl.org/source/openssl-3.0.7.tar.gz
• Pak het .tar.gz bestand uit (tar -xf openssl-3.0.7.tar.gz)
• Ga de folder openssl-3.0.7 in (cd openssl-3.0.7)
• Voer de volgende commando's één voor één uit:
  ./Configure
  make
  make test
  make install
• Herstart je server (misschien niet nodig? Ik heb het wel gedaan)
• Controleer of je nu de nieuwe versie hebt (openssl version)

[Reactie gewijzigd door Nilltris op 30 juli 2024 09:34]

[Oerdond3r]

Tenzij je al een zelf gecompilede installatie of een niet meer supported distro draait, kan je beter wachten op je package manager tot de nieuwe versie daarop staat, als die er niet al opstaat.

Zo weet je zeker dat jouw versie van openssl kwetsbaar was, en je niet een nieuwere 'major' versie installeert dan de versie die je al had waardoor er in theorie van alles stuk kan gaan.

[therijn]

Wie net als mij even aan het zoeken was naar hoe je OpenSSL kan updaten:....

Dit is de meest basale manier van updaten. Het zal werken maar het is beter om je package manager te gebruiken. Die houdt rekening met de versies en afhankelijkheden. Zo gebruikt mijn desktop openssl 1.1.1q omdat 3.0.5 nog in test staat.

[Reactie gewijzigd door therijn op 30 juli 2024 09:34]