Okta Red Team mengungkapkan kerentanan denial-of-service (DoS) pada OpenSSL yang diberi nama “HollowByte” — hanya 11 byte TLS request sudah cukup untuk mengalokasikan hingga 131 KB memori per koneksi, dan pada sistem glibc, memori tersebut tidak akan pernah dikembalikan ke kernel hingga process di-restart.
APA YANG TERJADI?
HollowByte dieksploitasi melalui TLS handshake message. Setiap message TLS memiliki 4-byte header, di mana 3 byte di antaranya mendeklarasikan panjang body. Versi lama OpenSSL langsung mengalokasikan receive buffer sebesar panjang yang dideklarasikan saat header diterima, sebelum satu byte body pun sampai, dan sebelum handshake checks berjalan.
Untuk inbound ClientHello, batas alokasi adalah 131 KB. Worker thread kemudian memblokir, menunggu body yang tidak pernah datang. Tidak ada autentikasi, tidak ada session, tidak ada key exchange yang terjadi — hanya koneksi menggantung yang menghabiskan memori.
DETAIL TEKNIS
Yang membuat HollowByte berbahaya adalah interaksi dengan glibc. Ketika attacker memutus koneksi, OpenSSL membebaskan buffer, tetapi glibc menahan small dan medium chunks untuk reuse daripada mengembalikannya ke kernel. Dengan memvariasikan ukuran yang dideklarasikan pada setiap koneksi, Okta berhasil mencegah allocator mereuse memori yang sudah dibebaskan.
Dalam pengujian NGINX oleh Okta, server 1 GB di-kill karena OOM dengan 547 MB memori membeku dalam fragmentasi. Pada server 16 GB, HollowByte mengunci 25% sistem memori tanpa pernah melampaui connection limit — yang berarti standard connection-limiting defenses tidak akan menghentikannya.
OpenSSL memperbaiki HollowByte pada Juni 2026 dalam rilis 4.0.1, 3.6.3, 3.5.7, 3.4.6, dan 3.0.21 — namun tanpa CVE, tanpa advisory, dan tanpa entry di changelog. Security team OpenSSL memilih untuk menangani ini sebagai “bug or hardening” fix, bukan sebagai vulnerability resmi. Tidak ada CVE yang ditugaskan, bahkan level Low pun tidak.
Penting untuk dicatat bahwa fix hanya mencakup TLS — DTLS tetap rentan karena perbaikan yang lebih menyeluruh akan terlalu invasif. Release yang sama juga menutup 18 CVE lainnya termasuk High-severity use-after-free di PKCS7_verify(), sehingga pengguna yang sudah update mendapat fix tanpa disadari.
DAMPAK TERHADAP INDONESIA
Server TLS di Indonesia — mulai dari web server e-government, banking gateway, hingga e-commerce — sangat rentan terhadap HollowByte. Banyak organisasi Indonesia menjalankan OpenSSL versi lama tanpa patch pipeline yang terstruktur. Karena tidak ada CVE, vulnerability scanner konvensional tidak akan mendeteksi kerentanan ini — membuat blind spot yang signifikan.
BSSN melalui SOCSIRT secara berkala menerbitkan advisori keamanan, namun HollowByte sendiri tidak tercantum karena tidak ada CVE. Tim SOC di Indonesia harus secara aktif memeriksa versi OpenSSL yang digunakan dan membandingkan dengan release yang sudah diperbaiki. Kominfo melalui SKKNI Siber mewajibkan organisasi kritis untuk melakukan vulnerability assessment berkala — ini termasuk memverifikasi status patch library fundamental seperti OpenSSL.
REKOMENDASI MITIGASI
1. Upgrade OpenSSL ke versi yang sudah diperbaiki: 4.0.1, 3.6.3, 3.5.7, 3.4.6, atau 3.0.21. 2. Periksa versi OpenSSL yang aktif — banyak distro Linux menampilkan versi via `openssl version`. 3. Implementasikan monitoring terhadap anomali memory usage pada server TLS. 4. Pertimbangkan penggunaan memory allocator alternatif yang tidak mempertahankan chunks seperti glibc. 5. Pantau pull request OpenSSL #30792, #30793, dan #30794 untuk memverifikasi patch yang diterapkan.
Analisa Retasan
Keputusan OpenSSL untuk tidak menugaskan CVE pada HollowByte adalah kebijakan yang sangat kontroversial. Okta membuktikan bahwa 11 byte sudah cukup untuk membekukan memori server secara permanen — ini jauh lebih berdampak dibandingkan banyak vulnerability yang justru mendapat CVE Low atau Moderate. Tanpa CVE, seluruh ekosistem keamanan — scanner, advisory, OVAL feeds — menjadi buta terhadap risiko ini.
Interaksi antara OpenSSL dan glibc inilah yang menjadikan HollowByte sangat berbahaya. Di atas kertas, alokasi 131 KB per koneksi memang kecil — tetapi ketika glibc menahan memory chunks dan fragmentasi terjadi secara kumulatif, dampaknya bisa membahayakan ketersediaan seluruh server. Ini mengingatkan bahwa vulnerability tidak selalu soal satu komponen — seringkali interaksi antar komponen yang menciptakan risiko sesungguhnya.
Bagi organisasi Indonesia, ini adalah pelajaran penting: jangan hanya bergantung pada scanner berbasis CVE. Tim SOC dan infrastruktur harus memiliki kemampuan untuk melakukan patch verification manual dan memory monitoring yang proaktif. Dalam dunia di mana vendor memilih untuk tidak menerbitkan advisory, security posture yang sehat harus mampu berdiri sendiri tanpa bergantung pada pipeline advisory konvensional.
Sumber: The Hacker News — OpenSSL HollowByte Flaw Could Freeze Server Memory
