OpenSSL loste het in juni op, zonder enige CVE

Elf bytes en een wachtende thread

Iemand van het Red Team van Okta stuurde een server 11 bytes en zag hoe die 131 kilobyte apart zette. De truc zit in de manier waarop een TLS-gesprek opent. De eerste vier bytes van een handshake-bericht geven aan hoe lang het bericht wordt, en oudere OpenSSL-versies geloofden die opgave en reserveerden de buffer voordat de rest binnenkwam of er enige controle liep. De rest van het bericht kwam nooit. Het geheugen bleef gereserveerd en een werkthread bleef wachten op gegevens die niet meer zouden komen.

Herhaald is dit allesbehalve subtiel. Op een server van één gigabyte liet het team 547 megabyte bevroren achter in onbruikbare fragmenten. Op een machine van zestien gigabyte legden ze een kwart van het totale geheugen vast. Op systemen met de glibc-allocator komt het geheugen ook na het verbreken van de verbinding niet netjes terug, omdat de vrijgegeven fragmenten niet herbruikbaar zijn. Er waren geen inloggegevens nodig, er kwam geen sessie tot stand, en niets aan de uitwisseling zag eruit als een aanval.

Het deel dat een bestuurder meer zou moeten verontrusten dan een ingenieur

OpenSSL heeft het verholpen. De versies 4.0.1, 3.6.3, 3.5.7, 3.4.6 en 3.0.21 verschenen allemaal op 9 juni 2026 met het gecorrigeerde gedrag: er wordt pas geheugen toegekend naarmate gegevens werkelijk binnenkomen. Drie samenvoegverzoeken, genummerd 30792, 30793 en 30794, droegen de wijziging. Daarna werd er ruim vijf weken niets over gezegd. De openbare bekendmaking bereikte de mailinglijst oss-security op 18 juli, 39 dagen nadat de correctie al in omloop was.

Het beveiligingsteam maakte een bewuste keuze. OpenSSL hanteert een ernstschaal met vier niveaus, van Kritiek tot Laag, en oordeelde dat dit geval in geen daarvan thuishoorde. Het samenvoegverzoek stelt onomwonden dat het team de melding wilde behandelen als een correctie van het type "bug of verharding". Er is dus geen CVE-aanduiding, geen beveiligingsadvies en geen vermelding in de wijzigingslogboeken van de betrokken uitgaven. Elk van die ontbrekende zaken is een beslissing, en elk daarvan verwijderde een signaal waarop iemands proces was gebouwd.

Het gedisciplineerde proces verloor van het ongedisciplineerde

Neem twee bedrijven. Het eerste patcht OpenSSL in een vast maandritme, ongeacht wat de uitgave bevat. Het is de aanpak die een volwassen beveiligingsfunctie doorgaans ontgroeit, omdat er wijzigingsvensters opgaan aan uitgaven die er niet toe doen. Dat bedrijf is sinds juni beschermd en heeft geen idee dat het ooit risico liep.

Het tweede prioriteert op ernst. Het leest de adviezen, scoort de CVE's, trekt Kritiek en Hoog naar voren en stelt de rest uit met een onderbouwde motivering. Dit is de aanpak die een audit doorstaat, een verzekeraar tevredenstelt en een bestuursvraag overleeft. Dat bedrijf bekeek de OpenSSL-uitgave van juni, vond geen beveiligingsinhoud en besloot volkomen terecht er geen wijzigingsvenster aan te besteden. Het is nog steeds blootgesteld, en het proces werkte precies zoals het ontworpen was.

De ongemakkelijke gevolgtrekking is dat patchen op ernst uw risicobeslissingen uitbesteedt aan degene die de ernst toekent. Dat is geen verwijt aan OpenSSL, een project dat grotendeels op vrijwilligers draait en verdedigbare keuzes maakt over een vierdelige schaal die het niemand verschuldigd is. Het is een vaststelling over waar het oordeel werkelijk ligt. Als uw proces alleen opschaalt wat al als gevaarlijk gelabeld binnenkomt, dan is uw dreigingsmodel in werkelijkheid het labelbeleid van uw leveranciers.

Twee dingen zijn vandaag nog steeds waar

Het DTLS-pad bleef ongemoeid. Het netjes verhelpen werd voorlopig te ingrijpend geacht, dus die code bepaalt zijn buffer nog altijd aan de hand van de lengte die de tegenpartij opgeeft. Handelt u ergens DTLS af, en dat doen veel VPN-concentrators, WebRTC-mediaservers en industriële IoT-gateways, dan is die blootstelling met niets van het hier beschrevene verholpen. Het is ook geen verborgen geheim. Het staat onomwonden in de bekendmaking, wat op zichzelf al een waarschuwing is.

Het tweede gaat over timing. Normaal komen bekendmaking en herstel samen en starten verdedigers en aanvallers op dezelfde lijn. Hier stond de gecorrigeerde code 39 dagen in openbare commits voordat iemand uitlegde wat die corrigeerde. Een commitvergelijking lezen is geen exotische vaardigheid. Ruim een maand lang hadden de mensen die code lezen een voorsprong op de mensen die bulletins lezen, en die tweede groep wist niet dat er een race was begonnen.

De vraag voor uw volgende patchoverleg

Bouw uw kwetsbaarhedenprogramma niet om vanwege één fout met geheugenuitputting. Voeg wel één terugkerende vraag toe aan het overleg dat u toch al houdt: wat hebben we dit kwartaal niet gepatcht omdat het zonder ernstclassificatie binnenkwam? Niet wat we als Laag hebben uitgesteld. Wel wat nooit in de wachtrij kwam omdat niets het labelde. Die lijst bestaat in elke organisatie en bijna niemand kijkt ernaar.

Vergelijk daarna uw OpenSSL-versies met de uitgaven van 9 juni, wat enkele minuten kost, en noteer of u beschermd bent door beleid of door geluk. Het verschil tussen die twee antwoorden is waar het om draait. Een beheersmaatregel die u per ongeluk beschermt is geen beheersmaatregel, en de volgende keer dat het toeval uitblijft merkt u dat op de dure manier.

Lees hierna: De fix was 81 dagen eerder openbaar dan de waarschuwing  |  Een verzoek kon uw WordPress-site kapen