Sebuah kerentanan di OpenSSL yang dinamakan HollowByte oleh Okta Red Team memungkinkan penyerang membekukan memori server hanya dengan mengirim request TLS sepanjang 11 byte. Kerentanan ini, yang diperbaiki oleh OpenSSL pada Juni 2026 tanpa CVE, advisory, atau entry changelog, menyerang server yang belum di-patch melalui mekanisme yang sangat sederhana namun sulit dideteksi.
APA YANG TERJADI?
Okta Red Team melaporkan kerentanan ini dan memberinya nama HollowByte. Inti masalahnya adalah OpenSSL mengambil kata-kata penyerang secara harfiah: setiap pesan handshake TLS membawa header 4 byte, di mana 3 byte di antaranya mendeklarasikan berapa lama body yang akan datang. Versi lama OpenSSL langsung mengalokasikan receive buffer sebesar yang dideklarasikan begitu header diterima, bahkan sebelum satu byte body pun muncul, dan sebelum pengecekan handshake berjalan.
Untuk inbound ClientHello, batas alokasi mencapai 131 KB per koneksi. Thread pekerja kemudian terblokir, menunggu body yang tidak pernah datang. Tidak perlu autentikasi, tidak perlu session, tidak perlu key exchange. Yang membuat HollowByte menjadi masalah serius adalah glibc — ketika penyerang memutus koneksi, OpenSSL membebaskan buffer, tetapi glibc menahan chunk kecil dan menengah untuk reuse alih-alih mengembalikannya ke kernel.
Serangan ini bervariasi dalam mengklaim ukuran di setiap koneksi, dan dalam pengujian Okta, variasi tersebut cukup untuk mencegah allocator menggunakan kembali memori yang dibebaskan. Heap terfragmentasi, resident set size meningkat, dan tetap meningkat jauh setelah penyerang pergi. Dalam pengujian NGINX oleh Okta, server 1 GB di-kill oleh OOM dengan 547 MB memori yang membeku dalam fragmentasi. Pada server 16 GB, HollowByte mengunci 25% memori sistem tanpa pernah melewati batas koneksi.
DETAIL TEKNIS
OpenSSL memutuskan untuk menangani ini sebagai “bug atau hardening” fix — bukan sebagai vulnerability. Kebijakan keamanan OpenSSL mendefinisikan empat tier severity dari Critical hingga Low, dan “bug atau hardening” bukan bagian dari tier manapun. Bahkan issue Low sekalipun mendapatkan CVE, catatan changelog, dan entry di halaman vulnerability. HollowByte tidak memiliki ketiganya.
Perbandingan yang menarik: pada Januari 2026, OpenSSL menetapkan CVE-2025-66199 (Low) untuk bug TLS 1.3 certificate-compression yang menumbuhkan heap buffer sebelum validasi, bernilai sekitar 22 MiB per koneksi. Bug itu membutuhkan empat kondisi berbaris: certificate compression di-compile, algorithm tersedia, extension dinegosiasi, dan (di server) client certificate diminta. HollowByte tidak membutuhkan satupun dari itu. Release yang sama (9 Juni) juga menetapkan CVE-2026-34183 (Moderate) untuk unbounded memory growth di QUIC PATH_CHALLENGE handler — keduanya memory-exhaustion DoS, keduanya mendapat nomor CVE.
Versi yang diperbaiki adalah OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, dan 3.0.21, semuanya bertanggal 9 Juni. Perbaikan hanya mencakup TLS — DTLS dibiarkan karena perubahan yang diperlukan akan terlalu invasif. Pull request menunjukkan bahwa DTLS handshake file byte-identik antara versi 3.6.2 dan 3.6.3. Di 4.0.1 (rilis terbaru), path DTLS masih mengalokasikan buffer berdasarkan panjang yang dideklarasikan peer.
DAMPAK TERHADAP INDONESIA
OpenSSL adalah tulang punggung keamanan komunikasi di hampir seluruh infrastruktur internet Indonesia. Dari web server, email server, hingga API gateway banking digital — semuanya bergantung pada OpenSSL untuk enkripsi TLS. Kerentanan ini berpotensi menargetkan jutaan server di Indonesia yang menjalankan versi OpenSSL yang belum diperbaiki.
Masalah terbesar bagi Indonesia adalah bagian downstream. Red Hat (yang menjadi dasar banyak distribusi Linux enterprise di Indonesia) menggunakan kebijakan backport alih-alih memutakhirkan versi. Artinya, package yang sudah di-patch masih melaporkan versi yang sama dengan yang dibangun. Yang biasanya menyelesaikan masalah ini adalah advisory dan OVAL feed, keduanya dikunci ke nama CVE. Tapi di sini tidak ada CVE. Satu-satunya jalan adalah memeriksa changelog package atau bertanya kepada maintainer apakah mereka rebased pada rilis 9 Juni atau mengambil patch (pull request 30792 untuk master dan 4.0, 30793 untuk 3.6/3.5/3.4, dan 30794 untuk 3.0).
BSSN sebagai lembaga keamanan siber nasional perlu segera menerbitkan peringatan terkait kerentanan ini, mengingat banyaknya infrastruktur pemerintah dan BUMN yang menjalankan OpenSSL. Tanpa CVE untuk di-track, scanner keamanan konvensional tidak akan mendeteksi kerentanan ini, menjadikannya “invisible vulnerability” yang sangat berbahaya bagi organisasi yang bergantung pada automated vulnerability scanning.
REKOMENDASI MITIGASI
Langkah paling mendesak adalah memutakhirkan OpenSSL ke versi yang sudah diperbaiki: 4.0.1, 3.6.3, 3.5.7, 3.4.6, atau 3.0.21 (semuanya bertanggal 9 Juni 2026). Setelah upgrade, restart semua layanan yang menggunakan OpenSSL. Jika membangun OpenSSL sendiri, pastikan mengambil patch dari pull request yang sesuai untuk branch yang digunakan.
Untuk organisasi yang tidak dapat segera upgrade, pertimbangkan mitigasi berikut: implementasikan rate limiting pada TLS connections, gunakan reverse proxy seperti NGINX atau HAProxy dengan connection limits yang ketat di depan server OpenSSL, dan monitor memory usage untuk mendeteksi anomali fragmentasi heap. Pertimbangkan juga penggunaan allocators alternatif seperti jemalloc atau tcmalloc yang mungkin tidak terpengaruh oleh fragmentasi glibc.
Periksa apakah DTLS digunakan di infrastruktur Anda — jika ya, kerentanan masih aktif bahkan di versi yang sudah di-patch. Pertimbangkan untuk mematikan DTLS jika tidak diperlukan. Terakhir, pastikan tim operations memiliki runbook untuk mengidentifikasi tanda-tanda serangan HollowByte: peningkatan mendadak RSS tanpa peningkatan koneksi aktif, fragmentasi heap yang tidak normal, dan OOM kills yang tidak dapat dijelaskan.
Analisa Retasan
Keputusan OpenSSL untuk tidak menetapkan CVE pada HollowByte menimbulkan pertanyaan serius tentang proses triaging keamanan di proyek open source kritis ini. Kerentanan yang memungkinkan server 1 GB di-kill oleh OOM dengan 547 MB memori yang membeku jelas memiliki dampak availability yang signifikan. Perbandingan dengan CVE-2025-66199 (certificate-compression bug yang membutuhkan 4 kondisi berbaris) dan CVE-2026-34183 (QUIC PATH_CHALLENGE handler) menunjukkan inkonsistensi dalam penerapan standar severity. HollowByte tidak membutuhkan kondisi apapun selain ability untuk mengirim TLS ClientHello — ini jauh lebih mudah dieksploitasi dibandingkan kedua CVE tersebut yang tetap mendapat nomor. Ketika patch tidak membawa CVE, seluruh ekosistem otomasi keamanan — scanner, SIEM rules, vulnerability management platforms — menjadi buta terhadap kerentanan ini.
Mekanisme teknis HollowByte sangat elegan dalam kesederhanaannya. Penyerang hanya perlu mengirim header TLS dengan ukuran body yang tidak wajar (hingga 131 KB), dan OpenSSL akan mengalokasikan memori untuk body tersebut sebelum validasi apapun terjadi. Yang membuat ini permanen bukan di OpenSSL, tetapi di glibc — allocator yang digunakan oleh mayoritas distribusi Linux. Glibc mempertahankan chunk untuk reuse alih-alih mengembalikannya ke kernel, dan variasi ukuran di setiap koneksi mencegah allocator menggunakan kembali chunk yang dibebaskan. Ini menciptakan fragmentasi heap yang progresif dan irreversibel. Pola ini mengingatkan pada serangan Slowloris klasik, tetapi dengan twist baru: bukan hanya menahan koneksi, tetapi membekukan memori secara permanen. Bahkan setelah serangan berhenti, dampaknya tetap ada hingga process di-restart.
Dari perspektif pertahanan Indonesia, ini adalah cerminan dari masalah mendasar dalam rantai dependensi software. Indonesia sangat bergantung pada upstream open source projects yang keputusan keamanannya mungkin tidak selalu selaras dengan kebutuhan defensif organisasi lokal. Tanpa CVE, tanpa advisory, dan tanpa entry di changelog, satu-satunya cara mengetahui apakah server Anda terdampak adalah dengan membaca source code OpenSSL secara manual atau membandingkan versi build. Untuk negara dengan ribuan server yang dikelola oleh tim yang terbatas, ini adalah tantangan operasional yang nyata. BSSN, KOMINFO, dan vendor cloud lokal seperti Biznet Gio, IDCloudHost, dan Indosat Ooredoo Hutchison perlu proaktif memverifikasi dan mengkomunikasikan status patch OpenSSL ke pelanggan mereka, karena scanner keamanan konvensional tidak akan membantu dalam kasus ini.
🔗 Sumber: The Hacker News — OpenSSL HollowByte Flaw Could Freeze Server Memory
