Tails brengt noodpatch uit om kwetsbaarheden in OpenSSL op te lossen

De Linux-distributie Tails heeft een noodpatch uitgebracht om meerdere kwetsbaarheden in OpenSSL op te lossen. De Tor-browser die in de oude versie van Tails zit, maakt gebruik van een kwetsbare versie van OpenSSL.

Het gaat om in totaal twaalf bekende kwetsbaarheden. Het lek met CVE-nummer CVE-2025-15467 is het ernstigst en heeft een CVSS-score van 9,8. Het gaat om een stackbufferoverflowfout die kan ontstaan bij het verwerken van Cryptographic Message Syntax-berichten. De parameter Initialization Vector, het 'startpunt' van de encryptie, wordt in een stackbuffer gekopieerd met een vaste grootte zonder te controleren of de lengte ervan geschikt is voor de buffer. Wanneer een aanvaller een CMS-bericht met een te grote IV verstuurt, ontstaat een stackbufferoverflow. Daardoor kan het systeem crashen en kan een hacker mogelijk op afstand code uitvoeren. De versies 3.6, 3.5, 3.4, 3.3 en 3.0 van OpenSSL bevatten dit lek.

De noodpatch repareert de kwetsbaarheden door de OpenSSL-bibliotheek te updaten naar versie 3.5.4. Volgens de ontwikkelaars van het op privacy gefocuste besturingssysteem was het door de kwetsbaarheden mogelijk om het IP-adres van een gebruiker te achterhalen via een kwaadaardige Tor-server. De patch updatet ook de Tor-client naar versie 0.4.8.22 en het e-mailprogramma Thunderbird naar versie 140.7.0. Verder lost de update ook een authenticatieprobleem met Gmail-accounts in Thunderbird op.

Reacties (30)

[meowmofo]

Het gaat om een stackbufferoverflowfout die kan ontstaan bij het verwerken van Cryptographic Message Syntax-berichten. De parameter Initialization Vector, het 'startpunt' van de encryptie, wordt in een stackbuffer gekopieerd met een vaste grootte zonder te controleren of de lengte ervan geschikt is voor de buffer. Wanneer een aanvaller een CMS-bericht met een te grote IV verstuurt, ontstaat een stackbufferoverflow. Daardoor kan het systeem crashen en kan een hacker mogelijk op afstand code uitvoeren.

Ik lees dit stukje tekst overal, maar snap bijzonder weinig van wat nou echt de implicaties hier zijn in het echte leven. Ik welke situaties zou dit uitgebuit kunnen worden? Zo te zien niet rechtstreeks tegen een webserver of iets, gezien ik wel al exploit / POC code online zie, maar nergens echt verder paniek om deze situatie.

[Damic]

Heel simpel: ze definiëren bvb een buffer van 1024byte, dan lezen ze de inivector in en steken die direct in die buffer, zonder te controleren of dat die inivector er wel in past.

De juiste methode is zodra ze de inivector hebben ingelezen dan eerst zien of dat stuk wel in de buffer past en dan pas naar de buffer verhuizen.

[Reactie gewijzigd door Damic op 31 januari 2026 11:34]

[ultimate-tester]

Juist. En door die overflow bereik je dus geheugen wat niet bereikt zou mogen worden. Als dat stukje geheugen instructies bevat die nog uitgevoerd moeten worden, en je plaatst dus uitvoerbare instructies in je bericht als aanvaller, dan bereik je hiermee dus dat je je eigen code kunt uitvoeren op afstand. Dit is overigens geen kansspel, je kunt als aanvaller gewoon de grootte van het bericht verhogen totdat je executeerbaar geheugen hebt bereikt

[Reactie gewijzigd door ultimate-tester op 31 januari 2026 11:21]

[halfgaar]

Het punt is meer dat het niet duidelijk is of dit voor een standaard TLS poort een RCE oplevert. Er wordt over getwist. De één zegt dat het niet kan omdat de exploit niet in dat onderdeel van OpenSSL zit. Anderen zeggen dat er wel een pad is te vinden, door bepaalde certificaten mee te sturen als client bijvoorbeeld.

Voor mij is dit een gevalletje: zekere voor het onzekere, dus gewoon snel updaten. En de services herstarten, anders heeft het geen zin. (Ubuntu heeft needrestart per default, dus dan ben je al gedekt).

Oh, en laten we niet alle gecontaineriseerde applicaties vergeten. Tegenwoordig vinden we het namelijk een goed idee om beveiligingsupdate uit de handen van de sysadmin naar de developers te verplaatsen.

[Reactie gewijzigd door halfgaar op 31 januari 2026 11:56]

[ShadowBumble]

[...]

Ik lees dit stukje tekst overal, maar snap bijzonder weinig van wat nou echt de implicaties hier zijn in het echte leven. Ik welke situaties zou dit uitgebuit kunnen worden? Zo te zien niet rechtstreeks tegen een webserver of iets, gezien ik wel al exploit / POC code online zie, maar nergens echt verder paniek om deze situatie.

Het uitvoeren van deze kwetsbaarheid resulterrd in een crash (at best case) van de applicatie. Hiermee kan dus iets onbereikbaar worden en voor bedrijven kan dat dus leiden tot een verlies aan inkomsten etc.


Ik zeg best case want soms kunnen deze type lwetsbaarheden er ook voor zorgen dat rr code uitgevoerd kan worden door geheugen manipulatie. Dit kan leiden tot toegang tot de server en dus een hack. Nu is daar op dit moment nog geen PoC voor maar dat is een lwestie van tijd.

[BartOtten]

"Nu is daar op dit moment nog geen publiek beschikbare PoC voor maar dat is een kwestie van tijd."

Fixed it

Het is mogelijk dat kwaadwillende dit al tijden misbruiken in plaats van de kwetsbaarheid te melden.

[Reactie gewijzigd door BartOtten op 31 januari 2026 13:24]

[killergrave]

Dood normaal als je het mij vraagt. Durf te wedden dat ze al exploit code werkende hebben op de nieuwste versie. Sommige van deze foutjes worden jaren en jaren misbruikt alvorens ze worden gefixt. Tegen de tijd dat ze zijn gefixt, zijn er alweer genoeg andere achterdeurtjes gevonden.

we horen al jaren dat instanties mensen op het dark web kunnen traceren, nou hier is dit een perfect voorbeeld van.

[Reactie gewijzigd door killergrave op 31 januari 2026 17:49]

[SunnieNL]

Risico op misbruik is gezet op low omdat je al op het systeem moet zijn met verhoogde rechten, wil je het kunnen misbruiken. Je moet dus nog een ander probleem hebben op het device wil men hier misbruik van kunnen maken.

Overigens meldt Google dat dezelfde cve ook gebruikt kan worden voor een ddos, waarschijnlijk omdat het openssl laat crashen en daarmee alle encrypte communicatie.

[R_Zwart]

Maar dat is wel precies hoe hackers werken. Iedere keer een klein stapje verder.

[FrostyPeet]

Je mag er rustig van uitgaan dat Tor/Tails netwerk tot de best gemonitorde systemen behoren. Denk aan onderzoekers, journalisten, overheden en veiligheidsdiensten in veel landen. In het verleden bleek dat sommige partijen er veel voor over hebben om gebruikers te vinden. Die verhalen zijn eenvoudig te vinden met je favoriete zoekmachine of op YouTube. Als er een bug is zal die zeker worden gevonden en uitgebuit. Als er een succesvolle POC is, wil dat niet zeggen dat die publiek bekend wordt gemaakt.

[bwerg]

Ik moet nu denken aan de obligate reactie "maar een veiligere programmeertaal garandeert nog steeds geen correct programma" die staat onder ongeveer elk artikel over developers die overstappen van C/C++ naar iets moderners - op dit moment vaak rust, maar dat had voor deze specifieke bug elke memory-managed taal kunnen zijn.

Bij deze de omgekeerde stelling, memory overflows veroorzaken een serieus risico en hadden in veel contexten al lang uitgebannen kunnen zijn, ongeacht welke domme fouten programmeurs ook kunnen maken.

[Reactie gewijzigd door bwerg op 31 januari 2026 11:52]

[Ablaze]

De vraag is alleen of we daarvoor programmeurs om moeten scholen en projecten van de grond af aan opnieuw moeten opzetten. Of dat we de rekenkracht en algoritmes die tegenwoordig alom beschikbaar zijn kunnen gebruiken om dit soort fouten in bestaande code automatisch op te sporen.

[_JGC_]

De vraag is of je volledig afhankelijk wilt zijn van tooling.

Ik werk dagelijks aan een legacy PHP project waar iemand heeft bedacht phpcs en phpstan validatie aan toe te voegen. Geweldig voor nieuwe code, maar de oude code zit in een baseline file. Soms moet ik iets aanpassen en los ik dan de ignores uit de baseline op. Resultaat is validatietools die blij zijn maar zodra je het script draait crasht het halverwege vanwege een type conflict. Operatie geslaagd, patiënt overleden. Die tooling is een hulpmiddel, geen garantie.

[Ablaze]

Dat soort fouten zullen überhaupt niet voorkomen bij compiled languages die strongly typed zijn, zoals de hier besproken C/C++. Die geeft op zijn minst warnings voor type conflicten en zou dat, met meer rekenkracht, ook kunnen geven voor buffer overruns en andere veelvoorkomende menselijke fouten, op het moment dat je op Compile drukt of zelfs continu tijdens het ontwikkelproces.

[farlane]

Dat soort fouten zullen überhaupt niet voorkomen bij compiled languages die strongly typed zijn, zoals de hier besproken C/C++

Als void* niet zou bestaan.....ook bij strongly typed languages zijn je types niet altijd safe.

[Reactie gewijzigd door farlane op 1 februari 2026 10:16]

[bwerg]

Het gaat hier over memory overflows, dat is een opgelost probleem waarvan de overhead aan rekenkracht soms significant is, maar vaak ook niet. Dat kan in C(++) net zo goed, door memory-access alleen via libraries te doen die de memory management voor je doen - dus expliciet bounds bijhouden en controleren.

En voor degenen die met voorbeelden komen waarin je in low-level code toch prestatiewinst weet te halen door geen bounds checking te doen, dat doe je weer deels teniet door stack canaries e.d. toe te voegen om buffer overflows te detecteren, want die kosten óók rekentijd. Of je doet dat óók niet en dan loop je met elk foutje in je geheugenmanagement nog veel meer risico.

[Reactie gewijzigd door bwerg op 31 januari 2026 16:45]

[SunnieNL]

Of de reactie dat open-source veel veiliger is omdat er zo veel mensen naar kijken. Hoe lang zit deze bug er al weer in? Waarschijnlijk vanaf september 2021 gezien openssl 3.0.0 toen uit kwam en deze cve ook daar op van toepassing is.

Enfin, dit gaat de komende weken heel veel updates opleveren, incl waarschijnlijk alle edge devices, omdat die veelal de openssl library gebruiken. Het is op zich wel verwonderlijk dat Tweakers het bij deze update meldt en niet toen de cve public gepost werd (want blijkbaar is er minimaal een maand gewerkt aan een Patch, gezien het jaartal 2025 in de cve) . Debian, Ubuntu En rocky hebben hun update ook al gehad. Ga er ook maar vanuit dat deze exploit snel misbruikt gaat worden, want naast rce levert deze vast ook crashes op waardoor er een ddos kan worden veroorzaakt.

[Reactie gewijzigd door SunnieNL op 31 januari 2026 16:07]

[R_Zwart]

Het statement zou eigenlijk moeten zijn: open source is in potentie veiliger omdat veel mensen er naar kunnen kijken. Maar ook in de oss community zullen veel developers het leuker vinden om nieuwe functionaliteit te bouwen dan bestaande code reviewen.

[Llopigat]

Ja maar sommige mensen vinden het wel leuk En het voordeel is ook; doordat het opensource is wordt dezelfde code in veel situaties gebruikt waardoor het ook onder ogen van meer auditors komt. Sommige bedrijven zullen zelfs voor audits betalen omdat ze dat moeten van bijv. een overheid als ze het in produktie gebruiken.

[_JGC_]

De updates aan OpenSSL stonden gisteren al tussen de downloads. In de comments staat ook een linkje naar een security blog die meer uitleg geeft bij deze release.

Er is een bedrijf die een AI tool ontwikkelt die door sourcecode gaat om dit soort bugs te vinden. Deze release van OpenSSL lost 12 CVEs op die met die tool zijn gevonden. Een aantal van die bugs zitten er al meer dan 25 jaar in en dateren van voor de eerste versie van OpenSSL.

Zonder sourcecode had die tool machinecode moeten analyseren en daarna had een mens er nog naar moeten kijken. Waarschijnlijk waren deze bugs dan helemaal niet boven water gekomen.

Opensource is overigens niet per definitie veiliger, want je kunt ook besluiten niks te melden en te gaan hacken met wat je gevonden hebt. Wel geeft opensource software je de mogelijkheid om zelf een fix te maken.

Jaren geleden draaide ik DNS servers op PowerDNS met LDAP als backend. Daar zat een escape fout in waardoor een DNS query met een backslash erin het backend proces liet crashen. Daar was ik al binnen een halfuur nadat iemand op een zondagmiddag die DoS op ons afvuurde achtergekomen en de fix heb ik zelf toegepast, code gecompileerd, in productie gezet en daarna gemeld bij de ontwikkelaars. Volgende release zat die fix erin. Probeer dat maar eens zo snel met closed source software opgelost te krijgen.

[Wolfos]

Ja, hetzelfde argument kan je ook maken over unit testing, static validation of zelfs linters. "Zolang je goed programmeert is het geen probleem" - uiteindelijk maakt iedereen bugs. Hoe meer, en hoe eerder je ze kunt afvangen, hoe beter.

Wolfos gaat verder met struct alignments debuggen want we kunnen niet altijd memory-safe zijn

[Aikon]

Een snelle zoekopdracht leert:

OpenSSL is widely used by software developers and system administrators to implement secure communication and encryption in various applications, such as web servers (like NGINX), email servers, VPNs, and more

Als er een kritiek lek in OpenSSL zit, waarom gaat dit bericht dan specifiek over Tails? Ik zou eerder een algemeen artikel over OpenSSL verwachten dan en welke producten er nog meer geraakt zijn, en of er patches beschikbaar zijn. Of mis ik iets en is alleen Tails echt geraakt hierdoor?

Ik zie dat de laatste 5 releases van OpenSSL een security release is met severity high. Dus lijkt vrij standaard dit

[Reactie gewijzigd door Aikon op 31 januari 2026 13:11]

[Niema]

Mogelijk was de reden dat de schrijver dacht dat het beter werkt om nieuws te schrijven over beveiligingsproblemen waar eindgebruikers last van hebben. Door specifiek voor tails te kiezen verhoogt dit ook de interesse in het artikel aangezien bij Tails een ip adres lek stuk relevanter klinkt dan elders. Er zijn een hoop libraries met beveiligingsproblemen en beveiligingsfixes. In dit geval werd het toegelicht. Een artikel posten waarbij men zegt: een bepaalde openssl bug kan ik sommige situaties lijden tot ip adress lek is een stuk minder interessant en hier werd uiteindelijk alles uiteindelijk toch toegelicht

[Aikon]

Ja ok, ik heb mijn bericht iets aangepast. Er komen veel ict-beheerders hier, en die zullen veel minder met Tails doen, maar des te meer met OpenSSL. Dat was meer mijn insteek van mijn vraag, is alleen Tails echt geraakt of vele producten en kan ik er best even induiken of ik iets met spoed moet patchen?

[Calypso]

Volgens mij had ik eerder deze week al OpenSSL updates gekregen voor Debian, dus het zal voor veel meer distro's van toepassing zijn.

[Knallmeister]

@Calypso

Klopt.

30-01-2026 • 16:30

download: OpenSSL 3.6.1 / 3.5.5 / 3.4.4 / 3.3.6 / 3.0.19 / 1.1.1ze / 1.0.2zn

[Reactie gewijzigd door Knallmeister op 31 januari 2026 21:10]

[Lednov]

"De patch updatet ook de Tor-client naar versie 0.4.8.22"
En twee dagen terug was dit op de FP:
Software-update: Tor Browser 15.0.5 - Computer - Downloads - Tweakers

Verschillende versie nummers vind ik nog al apart. Hoe zit dit?

[Cobalt]

Het is een paar dagen geleden pas opgelost. Op 27 januari https://github.com/openssl/openssl/releases/tag/openssl-3.5.5

[Llopigat]

Het is niet echt een distro. Het is een live "CD" om tor te kunnen gebruiken in een zo veilig mogelijke omgeving. Het is meer een soort tool op zichzelf met het OS er bij in. Bij normaal gebruik installeer je het ook niet, je draait het vanaf de live image zodat je elke keer een schoon image hebt dat geen sessiecookies enzo verzamelt.

[Reactie gewijzigd door Llopigat op 1 februari 2026 19:42]