OpenSSL kondigt update aan voor kritiek beveiligingslek

OpenSSL brengt op 1 november een patch uit om een kritiek beveiligingslek te dichten. Aangezien het om een kritieke kwetsbaarheid gaat, zijn er geen verdere details bekendgemaakt door de organisatie.

OpenSSL is een van de meestgebruikte opensourcebibliotheken voor cryptografie, waardoor een kritieke kwetsbaarheid erg gevaarlijk kan zijn. Het gebeurt vaker dat er een beveiligingslek wordt gevonden in OpenSSL, maar het gebeurt niet vaak dat deze van het hoogste risiconiveau is. OpenSSL schrijft dat de update dinsdagmiddag beschikbaar komt.

De kwetsbaarheid zit in versie 3.0 van OpenSSL en moet worden verholpen met de release van 3.0.7. In zijn securitybeleid schrijft OpenSSL dat informatie over kritieke beveiligingslekken niet wordt gedeeld. Via dit soort kwetsbaarheden is het bijvoorbeeld mogelijk om servers binnen te dringen en over te nemen of onderschepte communicatie te ontsleutelen.

Reacties (50)

[MiesvanderLippe]

Wat een hoop gedoe! Exploitable in de default (of Debian) config?

[gertvdijk]

Wat een hoop gedoe!

Nou, nog niet heel veel Linux-distributies populair voor servers zijn al over op 3.0.x.

Laatste Debian stable versie Bullseye (11) zit nog op 1.1.1. Debian testing Bookworm wel op 3.0.5.

Laatste Ubuntu LTS versie Jammy (22.04) zit op 3.0.2 en is dus wel affected, maar nog-supported 18.04 en 20.04 beide niet.

AlmaLinux 8.x zit nog op 1.1.1.
AlmaLinux 9.0 zit ook al wel op 3.0.1.

[Reactie gewijzigd door gertvdijk op 22 juli 2024 22:03]

[Verwijderd]

Aangezien er geen info over het lek is gedeeld waarschijnlijk niet in de configuratie op te lossen. Anders hadden ze nu de config settings gegeven die veilig/onveilig waren.

[Johan1995]

Het is toch open source? Je kan zelf de code checken en vaststellen waar het probleem zit!

[Pep7777]

Was het maar zo eenvoudig. Er staan geen links in de code die zeggen hier zit een foutje.
Het zijn vaak heel subtiele bugs (zeker als er meerdere threads tegelijk actief zijn). Of het zijn zelfs foutjes in de specificatie een complex protocol (en dan zie je de bug nog minder snel).

[mjtdevries]

Je hebt uiteraard gelijk, maar de opmerking van Johan1995 was natuurlijk ironisch/sarcastisch bedoeld.

Voorstanders van open source hebben in het verleden massaal geroepen dat het grote voordeel is dat je in de code kunt kijken en daardoor zelf beveiligings issues kunt opsporen.

Voor velen was duidelijk dat dat een onzinnig argument is, maar het bleef massaal geroepen worden.

[Reactie gewijzigd door mjtdevries op 22 juli 2024 22:03]

[Deleon78]

Ik denk dat je het argument verkeerd hebt begrepen. Het gaat over vrijheid, niet over dat “iedereen maar even bugs kan vinden”.
En ja, er zijn mensen die het letterlijk zijn gaan roepen.

[mjtdevries]

Ik heb het argument prima begrepen. Het zijn de mensen die dat riepen die het niet begrepen.

Er zijn een heleboel mensen die op basis van onzinnige argumenten voor open source zijn.
Dat betekent natuurlijk helemaal niet dat er geen goede argumenten voor open source zijn. Dat suggereer ik ook nergens.

[Deleon78]

Alright, eens!

[casberrypi]

Waarom denk je dat dit niet waar is?

Ik heb regelmatig bugs in software projecten opgelost waar ik niet de developer van was, maar gebruiker.

Dit issue in OpenSSL is waarschijnlijk opgelost binnen een jaar nadat het is gereleased, maar eigenlijk vrij kort nadat het op grote schaal gebruikt is gaan worden.

[D0phoofd]

Ja zeker! Als je hooggeleerd bent in wiskunde + expert in cryptografie EN in C kan programmeren, dan kan je daar je tijd nuttig aan spenderen.

[likewise]

Dan moet je wel feilloos in C kunnen programmeren, zonder exploits te creëren. Dat laatste lijkt nog het lastigste vaak, de crypto theorie zit vaak wel goed.

[bazzi]

Ok als ik het zo lees alleen 3.0.x en niet 1.1.1, want die is nog wel in support, maar de update is niet aangekondigd… of mis ik het nu?

The previous LTS version (the 1.1.1 series) is also available and is supported until 11th September 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used.

[Stephan1992]

CVE 2022-1292
Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd).

Zoals je kan zien is 1.1.1 wel affected tot en met 1.1.1n.

[bazzi]

Maar is het die cve wel? Want die was ook gefixed al in 3.0.3. Mijn vermoeden is dat het wat nieuws is, anders hoeft de embargo niet, want er is al een POC

UPDATE:
Iemand van openssl (en redhat) meld dat de cve wordt gepubliceerd op 1 nov en alleen in 3.0+ zit:
https://mobile.twitter.com/__agwa/status/1584916997472751618
Zie Mark J Cox antwoord. (Sorry ben geen twitter gebruiker, dus als ik de link kopieer zie ik wat anders dan alleen het antwoord wat ik wil tonen )

Ok en dan is 1.1.1s ook announced. Wordt alleen niks over "The highest severity issue
fixed in this release is CRITICAL" gemeld zoals bij 3.0.7:
https://mta.openssl.org/p.../2022-October/000238.html

[Reactie gewijzigd door bazzi op 22 juli 2024 22:03]

[Muncher]

Lang leven nitter.

https://nitter.it/__agwa/status/1584916997472751618#m

[ScharlakenRood]

https://nvd.nist.gov/vuln/detail/CVE-2022-3358

[Verwijderd]

Over een week pas. 😓
Daar gaan mensen zenuwachtig van worden vrees ik.

[johnny2000]

Zo werkt dat ... Onder embargo. Dit geeft iedereen (bijv. Red Hat en Ubuntu) de tijd om updates klaar te hebben voor de publicatie

[Blokker_1999]

Kans is groot dat vele projecten ook pas op dinsdag de code zullen krijgen van OpenSSL. Hoe meer mensen je toegang geeft, hij groter de kans dat er alsnog vroegtijdig informatie naar buiten komt.

Door nu aan te kondigen dat dit over een week wordt vrijgegeven kan iedereen in de keten zich voorbereiden om dinsdag zo snel mogelijk aan het patchen te gaan.

[Johan1995]

Ik dacht dat opensource en informatie delen een groot voordeel waren, maar blijkbaar is het net hoe de wind staat...

[TD-er]

Het is altijd een afweging tussen hoe snel je de "bad guys" op de hoogte wilt stellen en hoe snel je je patches getest en operationeel wilt hebben.

Ik kan mij niet herinneren dat er ooit eerder een dergelijke aankondiging geweest is van een aankomende patch die een week van tevoren werd aangekondigd.
Oftewel dit klinkt als een potentieel relatief makkelijk te exploiten bug en dan moet je dus ervoor zorgen dat je de boel ASAP kunt patchen voordat het voor de bad guys duidelijk is hoe dit te exploiten is.


Daarnaast slaat je opmerking op nog wel meer fronten de plank behoorlijk mis.
Als voorbeeld; Ik schrijf ook OpenSource software en ben extreem open in wat ik doe, waarom ik het doe, etc.
Maar zo heb ik ook code op mijn PC staan die uiteindelijk zeker wel in de openbaarheid zal komen alleen nu nog even niet.
Dit om de simpele reden dat ik het gewoon zelf eerst wel wil testen, omdat als mensen het zomaar zouden gaan testen zonder achtergrondinfo, dat ze erg veel schade kunnen aanrichten op hun eigen systemen.
Je zou kunnen aanvoeren dat "anderen mee kunnen testen" en op die manier alles zo snel mogelijk gedeeld gaat worden. Maar soms is het gewoonweg beter om er nog even mee te wachten alvorens het openbaar te maken.
In mijn geval (zeer concreet voorbeeld) gaat het om code waarbij ikzelf al een ESP boardje vrijwel onbruikbaar heb gemaakt en wat erg lastig weer werkende te krijgen is. Als ik een willekeurig iemand vraag ook die code te testen, gaat er dus serieus wat mis.

In het geval van de OpenSSL bug van dit artikel speelt er dus veel meer mee.
Daarbij wil je jezelf tijd geven om patches te testen en uit te rollen zodat wanneer de bug openbaar gemaakt zal worden, je tijd hebt om de boel te patchen voordat de aanvallen beginnen.

[ejabberd]

Ik kan mij niet herinneren dat er ooit eerder een dergelijke aankondiging geweest is van een aankomende patch die een week van tevoren werd aangekondigd.

Een week op voorhand weet ik niet, maar ik kan me wel meerdere keren herinneren dat het Drupal project me op voorhand via een security advisory aanmaande om me schrap te zetten. Voorbeeld.

[Verwijderd]

Partijen als redhat en debian compileren het in een paar uur. Dus dat lijkt me niet het issue. Maar als het ook naar embeds devices moet door rollen; dan kan het inderdaad wel wat meer tijd kosten.

[johnny2000]

Gelukkig ben jij geen software bedrijf ... Groot deel is Q/A en vaak doet Redhat backports van patches ... Wat nog meer testen inhoudt.

[latka]

Als het een oneliner is en het remote exploitable is (beide niet onwaarschijnlijk met het trackrecord van openssl) zou ik een langdurig testtraject overslaan als ik daarmee binnen een paar uur ipv. een paar dagen kan releasen.

[mocean]

Het punt met OpenSSL testen/bugs is: als je iets niet goed fixt&test kan je ook het toekomstige updateproces slopen (bijv. als er certificaten onterecht afgekeurd worden, o.i.d.).

[latka]

Tsja, dat is de afweging: een paar dagen exploitable (en ga er maar vanuit dat als er dinsdag een release is, er dinsdagavond een reverse engineering gedaan is voor een exploit en wellicht een kant en klaar script) of potentieel later een probleem. Het is een beetje kiezen tussen: zeker weten een probleem (te laat klaarstaan met je release) of misschien een probleem (je test effort wat verlagen). Ik weet wel wat ik kies. En daarbij: voor OpenSSL geldt dat het over het algemeen op Unix machines gebruikt worden. Die hebben geen update center en (meestal) beheerders die in dat geval handig genoeg zijn om met de hand een patch uit te rollen. Als je het kan voorkomen is dat beter, maar zoals ik aangaf: een paar dagen exploitable zijn lijkt me schadelijker omdat je dan niet weet wat je moet gaan fixen (is het alleen die machine of is men al via via het interne netwerk opgekomen en heeft men daar al wat malware neergezet voor het geval de voordeur gepatched wordt).

[coolkil]

Compileren misschien maar ga er vanuit dat hier ook een groot test traject voor is en dat kan een stuk langer duren

[Verwijderd]

In het nabije verleden deden ze het ook wel eens binnen een uur of 8 😉

[_JGC_]

En dan te bedenken dat 3.0.6 waarin ook al een beveiligingsfix zat is teruggetrokken vanwege regressies. Waarschijnlijk zijn ze bij het fixen daarvan tegen nog meer rotzooi aangelopen.

Bij 3.0.6 zat het lek in de implementatie van de legacy engine. Verklaart ook waarom 1.1.1 niet lek is.

[MarcelG]

Mmm. Hier word ik weer zenuwachtig van. De afgelopen weken viel me al op dat ik ineens 5+ meldingen per dag kreeg dat m'n Synology een IP ge-autoblocked had (voorheen max 1 per week).
Ik heb uit voorzorg maar de portforwarding uitgeschakeld tot Synology met een fix komt.

Deze waarschuwing stond er (in het Duits) een week geleden: https://www.news.de/techn...luecken-vom-17-10-2022/1/

[Reactie gewijzigd door MarcelG op 22 juli 2024 22:03]

[xbeam]

Je moet je nas ook niet met een portforward maar met een ZTNA tunnel online zetten. En daar zet je SSO koppeling op van een je IDP (Office,Azure,Google,Duo van Cisco enz.)

Dan gaat je firewall/ portforward naar vanzelf open wanneer jij of een andere vertrouweling via SSO aanklopt. voor rest is er geen of portforward te vinden.

[Tusk]

Is dat (SSO) ook met OpenVPN of Wireguard te fixxen?

[citroenie]

Interesting

Heb je een verwijzing naar een goede tutorial hiervan?
Mvg

[Onno]

OpenSSL is een van de meestgebruikte certificaten

🤔

OpenSSL is geen certificaat.

[Irsu85]

lijkt gepatched te zijn in de versie van 25 okt 19:07

[Drardollan]

Lijkt mij heel sterk dat ze iets wat volgende week pas als update beschikbaar komt vandaag al publiekelijk zouden builden.

Maar ik laat mij graag verrassen, heb je een betrouwbare bron?

[SuperDre]

Lol, je begreep zijn post niet.

[dutchgio]

Het gaat om het Tweakers bericht dat is 'gepatched' volgens mij, de opmerking over OpenSSL en certificaten is gecorrigeerd.

[Irsu85]

het bericht is gepatched inderdaad, van openssl weet ik het niet

[GeenBergTeHoog]

Klinkt goed. Bron?

[Soldaatje]

Tweakers is niet opensource.

[ViPER_DMRT]

OpenSSL.pem

[Tonkie1967]

Hebben ze het hier over https://cve.report/CVE-2022-1292 of is dit een ander issue?

[Bolukan]

indicatie: "Fixed in OpenSSL 3.0.3"

[DikkieDick]

Zie ik iets over het hoofd maar hoe komt het dat in de Debian Unstable (bullseye) 3.0.5 van juli 2022 zit?

[Tonkie1967]

Thanks. Zag het later ook
Dus vooralsnog geen cve nummer publiek bekend. Neem aan dat dat dan next Tuesday gebeurt

[kdekker]

OpenSSL heeft, net als bijna ieder ander software pakket dat er toe doet, al vaker veiligheidslekken gehad, maar publiceren dat ook netjes: https://www.openssl.org/news/vulnerabilities.html en een mooi grafiekje: https://www.cvedetails.co...penssl.html?vendor_id=217

Linux distributies lopen meestal iets achter op de actuele release, maar al zouden zelfs de openssl binaries niet op je systeem staan, dan nog zijn er een hoop andere producten die openssl (of een variant ervan) gebruiken.

Een lek is nooit fijn, maar zolang het mensenwerk is, zullen er ook lekken zijn ;-)

[Takkie]

Ze hebben vandaag informatie gedeeld op hun site.
https://www.openssl.org/b.../email-address-overflows/
https://www.openssl.org/news/secadv/20221101.txt

[Reactie gewijzigd door Takkie op 22 juli 2024 22:03]