Elleve byte og en ventende tråd

En fra Oktas Red Team sendte en server 11 byte og så den lægge 131 kilobyte til side. Kneb ligger i den måde, en TLS-samtale åbner på. De første fire byte i en håndtryksbesked angiver, hvor lang beskeden bliver, og ældre OpenSSL-versioner troede på den angivelse og reserverede bufferen, før resten ankom, eller nogen validering blev udført. Resten af beskeden kom aldrig. Hukommelsen forblev reserveret, og en arbejdstråd sad og ventede på data, der aldrig ville komme.

Gentaget er det ikke spor subtilt. På en server med én gigabyte efterlod holdet 547 megabyte frosset i ubrugelige fragmenter. På en maskine med seksten gigabyte låste de en fjerdedel af den samlede hukommelse. På systemer med glibc-allokatoren kommer hukommelsen ikke rent tilbage, selv efter angriberen har afbrudt forbindelsen, fordi de frigivne fragmenter ikke kan genbruges. Der krævedes ingen adgangsoplysninger, der blev ikke oprettet nogen session, og intet i udvekslingen lignede et angreb.

Den del, der bør bekymre en leder mere end en udvikler

OpenSSL rettede det. Versionerne 4.0.1, 3.6.3, 3.5.7, 3.4.6 og 3.0.21 udkom alle den 9. juni 2026 med den rettede adfærd, hvor der først tildeles hukommelse, efterhånden som data faktisk ankommer. Tre sammenfletningsanmodninger med numrene 30792, 30793 og 30794 bar ændringen. Derefter blev der ikke sagt noget om det i over fem uger. Den offentlige orientering nåede postlisten oss-security den 18. juli, 39 dage efter at rettelsen allerede var ude.

Sikkerhedsholdet traf et bevidst valg. OpenSSL kører et alvorsgradssystem i fire trin, fra Kritisk til Lav, og vurderede, at dette tilfælde ikke hørte hjemme i nogen af dem. Sammenfletningsanmodningen fastslår klart, at holdet valgte at behandle indberetningen som en rettelse af typen "fejl eller hærdning". Der findes derfor ingen CVE-betegnelse, intet sikkerhedsvarsel og intet punkt i ændringsloggene for de berørte udgivelser. Hvert af disse fravær er en beslutning, og hvert af dem fjernede et signal, som nogens proces var bygget til at opfange.

Den disciplinerede proces tabte til den udisciplinerede

Tænk på to virksomheder. Den første opdaterer OpenSSL i en fast månedlig takt uanset hvad udgivelsen indeholder. Det er den tilgang, en moden sikkerhedsfunktion gerne vokser fra, fordi den bruger ændringsvinduer på udgivelser uden betydning. Den virksomhed har været beskyttet siden juni og aner ikke, at den nogensinde var udsat.

Den anden prioriterer efter alvorsgrad. Den læser varslerne, scorer CVE'erne, fremrykker Kritisk og Høj og udskyder resten med en dokumenteret begrundelse. Det er den tilgang, der består en revision, tilfredsstiller et forsikringsselskab og holder til et spørgsmål i bestyrelsen. Den virksomhed så på OpenSSL-udgivelsen fra juni, fandt intet sikkerhedsindhold og besluttede helt korrekt ikke at bruge et ændringsvindue på den. Den er stadig udsat, og processen virkede nøjagtigt som tiltænkt.

Den ubehagelige slutning er, at opdatering efter alvorsgrad lægger jeres risikobeslutninger ud til den, der tildeler alvorsgraden. Det er ikke en kritik af OpenSSL, et projekt båret i høj grad af frivillige, som træffer forsvarlige valg om en firetrinsskala, det ikke skylder nogen. Det er en konstatering af, hvor dømmekraften reelt ligger. Hvis jeres proces kun eskalerer det, der ankommer forhåndsmærket som farligt, så er jeres trusselsmodel i virkeligheden jeres leverandørers mærkningspolitik.

To ting gælder stadig i dag

DTLS-stien blev ladt i fred. At rette den ordentligt blev vurderet for indgribende indtil videre, så den kode fastsætter fortsat sin buffer ud fra den længde, modparten oplyser. Afslutter I DTLS et sted, og det gør mange VPN-koncentratorer, WebRTC-medieservere og industrielle IoT-gateways, så er den risiko ikke afhjulpet af noget som helst beskrevet her. Det er heller ikke en skjult hemmelighed. Det står åbent i orienteringen, hvilket i sig selv er en advarsel.

Det andet handler om tidsforløbet. Normalt kommer orientering og rettelse samtidig, og forsvarere og angribere starter på samme linje. Her lå den rettede kode i offentlige ændringer i 39 dage, før nogen forklarede, hvad den rettede. At læse en ændringssammenligning er ingen eksotisk færdighed. I over en måned havde de, der læser kode, en fordel frem for dem, der læser bulletiner, og den anden gruppe vidste ikke, at et kapløb var begyndt.

Spørgsmålet til jeres næste patchgennemgang

Byg ikke jeres sårbarhedsprogram om på grund af én fejl med hukommelsesudtømning. Men tilføj ét tilbagevendende spørgsmål til det møde, I alligevel holder: hvad afstod vi fra at opdatere i dette kvartal, fordi det kom uden en alvorsgrad? Ikke det, vi udskød som Lav. Men det, der aldrig kom i køen, fordi intet mærkede det. Den liste findes i enhver organisation, og næsten ingen kigger på den.

Sammenhold derefter jeres OpenSSL-versioner med udgivelserne fra 9. juni, hvilket tager minutter, og noter, om I er dækket af politik eller af held. Forskellen mellem de to svar er hele pointen. En kontrol, der beskytter jer ved et tilfælde, er ingen kontrol, og næste gang tilfældet udebliver, finder I ud af det på den dyre måde.

Læs videre: Rettelsen var offentlig 81 dage før advarslen  |  En forespørgsel kunne kapre din WordPress-side