Tizenegy bájt is elég ahhoz, hogy egy nem frissített OpenSSL szerver akár 131 KB memóriát félretegyen egy olyan üzenetnek, amely soha nem érkezik meg. Az Okta által vizsgált glibc-alapú rendszereken ez a memória addig nem szabadul fel, amíg az adott folyamatot újra nem indítják.

Az OpenSSL júniusban kiadta a HollowByte javítást, de nem kapott CVE-azonosítót, nem jelent meg róla biztonsági közlemény, és a changelog sem hivatkozik rá. Az Okta Red Teamje, amely bejelentette a szolgáltatásmegtagadásos hibát és nevet is adott neki, csütörtökön hozta nyilvánosságra a részleteket.

A javítást tartalmazó kiadások az OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 és 3.0.21, mindegyik június 9-i dátummal. Ezek előtt az adott ágon megjelent összes kiadás érintett. Egy szokásos javítócsomag-pipeline nem fog rámutatni ezekre a verziókra: nincs azonosító, amit egy szkenner felismerhetne, és nincs biztonsági közlemény, amit el lehetne olvasni.

A hiba lényege, hogy az OpenSSL elhitte a támadónak, amit az állít. Minden TLS kézfogás-üzenet 4 bájtos fejléccel érkezik, ebből három bájt adja meg a törzs hosszát. A régebbi verziók már akkor a megadott méretre növelték a fogadó puffer méretét, amikor a fejléc megérkezett – még azelőtt, hogy a törzsből akár egyetlen bájt is befutott volna, és mielőtt a kézfogás saját ellenőrzései lefutottak volna.

Bejövő ClientHello esetén a felső határ 131 KB. Ezután a worker szál blokkol, és vár egy törzsre, amely soha nem érkezik meg. Nincs hitelesítés, nincs session, nincs kulcscsere.

A memória nem szabadul fel

Önmagában ez egy kapcsolat-kimerítéses támadás, ilyenek Slowloris óta léteznek. Amitől a HollowByte igazán kellemetlenné válik, az a glibc viselkedése. Amikor a támadó bontja a kapcsolatot, az OpenSSL felszabadítja a puffert, de a glibc a kisebb és közepes méretű blokkokat újrafelhasználásra félreteszi, ahelyett hogy visszaadná őket a kernel-nak.

A támadás minden kapcsolatnál változtatja a bemondott méretet, és az Okta tesztjei szerint ez már elég ahhoz, hogy az allokátor ne tudja újra felhasználni a felszabadított blokkokat. A heap széttöredezik, a resident set mérete megugrik, és jóval a támadás befejezése után is magasan marad.

Okta NGINX-tesztjeiben egy 1 GB memóriával rendelkező szervert OOM-killer állította le, miközben 547 MB memória „fagyott be” töredékekben. Egy 16 GB-os szerveren a HollowByte a rendszer memóriájának 25%-át kötötte le úgy, hogy közben soha nem lépte át a kapcsolatlimit felső határát. Ezért állítja a Red Team, hogy „a szokásos kapcsolat-limitáló védelmek nem állítják meg”.

Ezek az adatok az Okta saját mérései, és nem tett közzé hozzájuk exploit kódot. A Hacker News július 18-ig nem talált nyilvános proof-of-concept tárolót a GitHub-en.

Az OpenSSL szerint ez nem sebezhetőség

Matt Caswell javítási pull requestje, aki a patch-et írta, egyértelműen fogalmaz: a security csapat úgy döntött, hogy „csak hiba- vagy hardening-jellegű javításként” kezeli az ügyet. Az OpenSSL saját biztonsági szabályzata négy súlyossági szintet határoz meg a Criticaltől a Low-ig, a „bug or hardening” kategória nem szerepel köztük.

Még egy Low besorolású probléma is kap CVE-azonosítót, changelog-bejegyzést és felkerül a sebezhetőségek oldalára. A HollowByte egyikből sem részesült. A Hacker News nem talált említést a javításról sem a kiadási megjegyzésekben, sem az OpenSSL 4.0.1-es changelogjának 23 bejegyzése között.

Az OpenSSL nem indokolta a döntést. A mellettük szóló érvek: 131 KB kapcsolatként nem sok, minden TLS szerver foglal memóriát kapcsolatonként, és egy felső határral rendelkező allokáció önmagában nem sebezhetőség. Az Okta válasza erre az, hogy a memória gyakorlatilag nem kerül vissza a rendszerhez.

A Hacker News megkérdezte az OpenSSL-t, miért sorolták a HollowByte-ot a Low alá, és hogy a javítás eljutott-e az extended-support alatt álló 1.1.1-es és 1.0.2-es ágakra. Az Oktától azt is megkérdezték, hogy a töredezettség más allokátorok esetén is fennmarad-e, vagy ez kifejezetten glibc-specifikus. Ha érkezik válasz, frissítik a cikket.

A projekt határvonala finomabb, mint elsőre látszik. Januárban az OpenSSL CVE-2025-66199 azonosítót adott, Low besorolással, egy TLS 1.3 certificate-compression hibának, ahol egy partner által megadott hossz ellenőrzés előtt növelte meg a heap puffert, kapcsolatként nagyjából 22 MiB-ig.

Ott négy feltételnek kellett egyszerre teljesülnie: be kellett fordítani a certificate compression funkciót, elérhetőnek kellett lennie egy tömörítési algoritmusnak, le kellett tárgyalni a kiterjesztést, és szerveroldalon kérni kellett a kliens tanúsítványokat. A HollowByte-hoz egyik sem kell.

Ugyanennek a június 9-i kiadásnak a része a CVE-2026-34183 is, Moderate besorolással, amely a QUIC PATH_CHALLENGE kezelőjében okoz korlátlan memória-növekedést. Mindkettő memória-kimerítéses DoS. Mindkettő kapott CVE-azonosítót.

A kiadás összesen 18 CVE-t zárt le, köztük egy High súlyosságú use-after-free hibát a PKCS7_verify() függvényben, így aki ezeket az upstream buildeket futtatja, már megkapta a HollowByte javítását is, anélkül hogy erről külön tájékoztatták volna.

Downstream oldalon rosszabb a helyzet. A Red Hat dokumentált alapértelmezése a backportolás, nem a verzióváltás, így egy javított csomag továbbra is azt a verziószámot jelenti, amelyből eredetileg fordították. Normál esetben ezt a bizonytalanságot a biztonsági közlemény és az OVAL feed oldja fel, mindkettő CVE-azonosítókhoz kötve. Itt viszont nincs CVE, amihez kötni lehetne bármit.

Marad a csomag changelogja vagy a karbantartó megkérdezése: kideríteni, hogy átrebaselték-e a csomagot a június 9-i kiadásra, vagy külön vették át a patch-et. A javítás pull request számai: 30792 a master és a 4.0 ág számára, 30793 a 3.6, 3.5 és 3.4 ágakhoz, valamint 30794 a 3.0-hoz.

Ha saját magad fordítod az OpenSSL-t, végezz verziófrissítést a felsorolt kiadások valamelyikére, és indítsd újra az összes komponenst, amely a régi könyvtárat betöltötte.

A javítás csak a TLS-t érinti. Caswell a pull requestben leírta, hogy a DTLS-hez nem nyúltak, mert a helyes megoldás jóval mélyebb beavatkozást igényelt volna, és a projekt egyelőre úgy döntött, hogy nem foglalkozik vele. A Hacker News összehasonlította az OpenSSL forrását a 3.6.2 és 3.6.3 tageknél, és a DTLS kézfogásért felelős fájl bájtról bájtra azonos maradt a javítás után is. A legújabb, 4.0.1-es kiadásban ez az útvonal továbbra is a partner által megadott hossz alapján méretezi a puffert.

Az OpenSSL nem sorolta be ezt az útvonalat, és nem vállalt kötelezettséget a javítására. A kiadási megjegyzések, a changelog és a sebezhetőségek oldala sem említi. A pull request viszont igen.

Az OpenSSL triagere szerint ez üzemeltetési kérdés, nem protokollhiba

Frissítés (2026. július 20.): Alexandr Nedvedicky, a HollowByte-ot triage-oló OpenSSL fejlesztő a cikk megjelenése után válaszolt a Hacker Newsnak.

Elválasztotta egymástól a HollowByte-ot és azt a QUIC hibát, amely idén júniusban CVE-t kapott. A QUIC hibát szerinte protokollprobléma okozza, mert a kód nem szab felső határt arra, hány PATH_CHALLENGE keretet fogad el. A HollowByte az ő értelmezésében inkább arról szól, hogy a szervert blokkoló módban, korlátok nélkül hagyták, ami közelebb áll egy üzemeltetési döntéshez, mint egy protokollszintű hibához.

A jelentést OpenBSD-n triage-olta, amely nem glibc-t használ, és elmondása szerint „nem vette figyelembe a glibc-ből esetlegesen következő hatásokat”. Márpedig az Okta érvelésének központi eleme éppen ez a viselkedés.

Abban sem volt biztos, hogy a mostani javítás ténylegesen megoldja a problémát. Caswell patch-e óvatosabban növeli a puffer méretét, de továbbra is reallocot használ, Nedvedicky pedig úgy fogalmazott, hogy „nem biztos benne, javít-e ez bármit glibc alatt”. Az Okta ennek ellenére frissítést javasol.

Arra a kérdésre, hogy a javítás eljutott-e az extended-support alatt álló 1.1.1-es és 1.0.2-es ágakra, nem válaszolt, és az OpenSSL support portáljára irányította a kérdezőket.