Elva byte och en väntande tråd

Någon i Oktas Red Team skickade en server 11 byte och såg den lägga undan 131 kilobyte. Knepet ligger i hur ett TLS-samtal inleds. De första fyra byten i ett handskakningsmeddelande anger hur långt meddelandet blir, och äldre OpenSSL-versioner trodde på den uppgiften och reserverade bufferten innan resten anlände eller någon validering kördes. Resten av meddelandet kom aldrig. Minnet förblev reserverat och en arbetstråd satt och väntade på data som aldrig skulle komma.

Upprepat är detta allt annat än subtilt. På en server med en gigabyte lämnade laget 547 megabyte frusna i oanvändbara fragment. På en maskin med sexton gigabyte låste de en fjärdedel av det totala minnet. På system med glibc-allokatorn kommer minnet inte tillbaka rent ens efter att angriparen kopplat ned, eftersom de frigjorda fragmenten inte går att återanvända. Det behövdes inga inloggningsuppgifter, ingen session upprättades, och ingenting i utbytet såg ut som ett angrepp.

Den del som bör oroa en chef mer än en ingenjör

OpenSSL rättade det. Versionerna 4.0.1, 3.6.3, 3.5.7, 3.4.6 och 3.0.21 kom alla den 9 juni 2026 med det rättade beteendet, där minne tilldelas först i takt med att data verkligen anländer. Tre sammanslagningsbegäranden, numrerade 30792, 30793 och 30794, bar ändringen. Sedan sades ingenting om saken på över fem veckor. Den offentliga redogörelsen nådde e-postlistan oss-security den 18 juli, 39 dagar efter att rättelsen redan var ute.

Säkerhetsgruppen gjorde ett medvetet val. OpenSSL driver ett system för allvarlighetsgrad i fyra steg, från Kritisk till Låg, och bedömde att detta fall inte hörde hemma i något av dem. Sammanslagningsbegäran slår klart fast att gruppen valde att hantera rapporten som en rättelse av typen "fel eller härdning". Det finns därför ingen CVE-beteckning, inget säkerhetsmeddelande och ingen post i ändringsloggarna för de berörda utgåvorna. Var och en av dessa uteblivna uppgifter är ett beslut, och var och en tog bort en signal som någons process var byggd för att fånga upp.

Den disciplinerade processen förlorade mot den odisciplinerade

Tänk er två företag. Det första uppdaterar OpenSSL i fast månadstakt oavsett vad utgåvan innehåller. Det är det arbetssätt som en mogen säkerhetsfunktion gärna växer ifrån, eftersom det förbrukar ändringsfönster på utgåvor utan betydelse. Det företaget har varit skyddat sedan juni och har ingen aning om att det någonsin var utsatt.

Det andra prioriterar efter allvarlighetsgrad. Det läser meddelandena, poängsätter CVE-posterna, tidigarelägger Kritisk och Hög och skjuter upp resten med en dokumenterad motivering. Det är arbetssättet som klarar en revision, tillfredsställer ett försäkringsbolag och håller för en fråga i styrelsen. Det företaget tittade på OpenSSL-utgåvan från juni, fann inget säkerhetsinnehåll och beslutade helt riktigt att inte lägga ett ändringsfönster på den. Det är fortfarande utsatt, och processen fungerade precis som den var konstruerad.

Den obekväma slutsatsen är att uppdatera efter allvarlighetsgrad innebär att lägga ut sina riskbeslut på den som sätter allvarlighetsgraden. Det är ingen anklagelse mot OpenSSL, ett projekt som till stor del bärs av frivilliga och som fattar försvarbara beslut om en fyrgradig skala det inte är skyldigt någon. Det är ett konstaterande om var omdömet faktiskt ligger. Om er process bara eskalerar det som anländer färdigmärkt som farligt, då är er hotmodell i själva verket era leverantörers märkningspolicy.

Två saker gäller fortfarande i dag

DTLS-vägen lämnades ifred. Att rätta den ordentligt bedömdes som alltför ingripande tills vidare, så den koden dimensionerar fortfarande sin buffert efter den längd motparten uppger. Avslutar ni DTLS någonstans, och det gör många VPN-koncentratorer, WebRTC-medieservrar och industriella gatewayer för sakernas internet, då är den exponeringen inte åtgärdad av något som beskrivits här. Det är inte heller någon dold hemlighet. Det sägs öppet i redogörelsen, vilket i sig är en varning.

Det andra gäller tidsförloppet. Normalt kommer redogörelse och rättelse samtidigt, och försvarare och angripare startar vid samma linje. Här låg den rättade koden i offentliga ändringar i 39 dagar innan någon förklarade vad den rättade. Att läsa en ändringsjämförelse är ingen exotisk färdighet. I över en månad hade de som läser kod ett övertag över dem som läser bulletiner, och den andra gruppen visste inte att en kapplöpning hade börjat.

Frågan att lägga till vid nästa genomgång

Bygg inte om ert sårbarhetsarbete på grund av ett enda fel med minnesutmattning. Lägg däremot till en återkommande fråga vid den genomgång ni ändå håller: vad avstod vi från att uppdatera detta kvartal för att det kom utan allvarlighetsgrad? Inte det vi sköt upp som Låg. Utan det som aldrig kom in i kön för att ingenting märkte det. Den listan finns i varje organisation och nästan ingen tittar på den.

Jämför sedan era OpenSSL-versioner med utgåvorna från 9 juni, vilket tar minuter, och notera om ni är täckta av policy eller av tur. Skillnaden mellan de två svaren är hela poängen. En kontroll som skyddar er av en slump är ingen kontroll, och nästa gång slumpen uteblir får ni veta det på det dyra sättet.

Läs vidare: Rättningen var offentlig 81 dagar före varningen  |  En begäran kunde kapa din WordPress-sajt