Okta Red Team offentliggjorde torsdag detaljene om HollowByte, en tjenestenekt-feil i OpenSSL de selv rapporterte og navnga, ifølge The Hacker News. Kjernen er enkel: hver TLS-handshake starter med et fire-byte-hode der tre byte oppgir hvor stor meldingskroppen blir. Eldre OpenSSL vokste mottaksbufferen til den oppgitte størrelsen med én gang hodet landet, før en eneste byte av kroppen kom og før handshaken rakk sine egne sjekker. For en innkommende ClientHello er taket 131 KB, og angriperen trenger verken autentisering eller nøkkelutveksling.
Alvoret ligger i glibc. Når angriperen slipper tilkoblingen, frigir OpenSSL bufferen, men glibc holder på små og mellomstore biter for gjenbruk i stedet for å gi dem tilbake til kjernen. Ved å variere den oppgitte størrelsen på hver tilkobling fragmenterer heapen, og minnet blir værende lenge etter at angriperen er borte. I Oktas NGINX-test ble en 1 GB-server drept av OOM-killer med 547 MB låst i fragmenter.
«Standard tilkoblingsbegrensende forsvar stopper den ikke.»
Det er Okta Red Teams poeng: fordi minnet aldri kommer tilbake, holder det ikke å kappe antall samtidige tilkoblinger. De fiksede versjonene er OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 og 3.0.21, alle datert 9. juni. Haken er at OpenSSL valgte å behandle dette som en «bug or hardening»-fiks, ikke en sårbarhet, så det finnes ingen CVE en skanner kan matche og ingen advisory å lese. DTLS-stien er dessuten fortsatt urørt.
Hva bør du gjøre?
- Bygger du OpenSSL selv, oppgrader til en av de listede versjonene og restart alt som lastet det gamle biblioteket.
- Kjører du en distro-pakke, spør vedlikeholderen om de rebaset på 9. juni-utgivelsen eller tok patchen (PR 30792, 30793 eller 30794), siden ingen CVE finnes å søke på.