Tim Red Team Okta menemukan sebuah kerentanan Denial of Service (DoS) pada OpenSSL yang dinamakan “HollowByte”. Kerentanan ini memungkinkan penyerang remote untuk membekukan sebagian besar memori server hanya dengan mengirimkan payload berukuran 11 byte selama proses TLS handshake. Temuan ini mengungkap bagaimana kepercayaan buta terhadap ukuran yang dideklarasikan oleh klien dapat menghancurkan disponibilitas server.
APA YANG TERJADI?
Okta Red Team menemukan kerentanan DoS kritis pada OpenSSL yang mereka beri nama “HollowByte”. Mekanisme serangannya elegan namun menghancurkan: penyerang mengirimkan TLS ClientHello dengan header yang mendeklarasikan ukuran body tertentu, dan OpenSSL memperlakukan deklarasi ini sebagai kebenaran mutlak. Fungsi OPENSSL_clear_realloc() kemudian memanggil malloc() dengan ukuran yang dideklarasikan oleh penyerang, yang dapat mencapai hingga 131KB untuk satu request tunggal.
Masalah sebenarnya terjadi pada level alokasi memori sistem operasi. Alokator memori glibc memiliki kecenderan untuk mempertahankan chunk memori yang telah dibebaskan (freed chunks) dalam cache internalnya untuk optimasi performa. Ketika pola alokasi dan pembebasan ini diulang oleh ribuan request simultan, terjadi fragmentasi heap yang parah. Akibatnya, Resident Set Size (RSS) server terus meningkat meskipun secara logika memori seharusnya sudah dibebaskan.
DETAIL TEKNIS
Pada server dengan RAM 1GB, serangan HollowByte dapat menyebabkan proses server mencapai kondisi OOM-killed (Out-Of-Memory killed) ketika frozen memory mencapai 547MB. Pada server yang lebih besar dengan 16GB RAM, serangan serupa dapat mengunci sekitar 25% dari total kapasitas memori yang tersedia. Dampak ini bersifat proporsional terhadap ukuran server, menjadikan serangan ini efektif pada berbagai skala infrastruktur.
Kerentanan ini mempengaruhi hampir seluruh ekosistem server web modern, termasuk Apache, NGINX, Node.js, Python, Ruby, PHP, MySQL, dan PostgreSQL. Cakupan yang luas ini menjadikan HollowByte sebagai ancaman serius bagi sebagian besar infrastruktur web yang beroperasi saat ini. Para peneliti telah menyerahkan perbaikan melalui PR #30792, #30793, dan #30794 di repositori OpenSSL.
Perbaikan telah diam-diam disertakan dalam OpenSSL v4.0.1 dan backport ke versi 3.6.3, 3.5.7, 3.4.6, dan 3.0.21. Menariknya, perbaikan ini diklasifikasikan sebagai “hardening fix” dan bukan sebagai advisory CVE formal, sehingga banyak organisasi mungkin tidak menyadari pentingnya pembaruan ini. Pola serangan ini secara konseptual mirip dengan serangan Slowloris klasik, di mana penyerang memanfaatkan cara server menangani koneksi yang lambat atau tidak lengkap untuk menghabiskan sumber daya.
DAMPAK TERHADAP INDONESIA
OpenSSL merupakan tulang punggung enkripsi untuk sebagian besar infrastruktur internet di Indonesia, mulai dari portal e-government, layanan perbankan digital, hingga platform e-commerce. Kerentanan DoS pada level TLS handshake ini sangat berbahaya karena menargetkan titik paling dasar dari komunikasi terenkripsi, yaitu proses inisialisasi koneksi SSL/TLS.
Organisasi di Indonesia yang mengandalkan OpenSSL pada server web dan database mereka berpotensi mengalami gangguan layanan massal jika kerentanan ini dieksploitasi. BSSN telah lama menekankan pentingnya pemeliharaan patch pada software kritis, namun kenyataannya banyak server di Indonesia masih menjalankan versi OpenSSL yang belum diperbarui. Klasifikasi perbaikan ini sebagai “hardening fix” alih-alih advisory CVE formal semakin memperparah masalah ini, karena banyak sistem pemantauan otomatis yang tidak akan menganggap pembaruan ini sebagai kritis.
Untuk sektor perbankan dan fintech di Indonesia yang wajib mematuhi regulasi OJK terkait keamanan siber, kerentanan DoS ini dapat berdampak langsung pada ketersediaan layanan keuangan digital yang menjadi bagian integral dari operasional harian jutaan nasabah.
REKOMENDASI MITIGASI
Perbarui OpenSSL ke versi 4.0.1 atau versi backport terbaru (3.6.3, 3.5.7, 3.4.6, atau 3.0.21) pada seluruh server yang menjalankan layanan TLS. Prioritaskan server yang menghadap internet dan memproses volume koneksi TLS tinggi.
Implementasikan rate limiting pada level load balancer atau firewall untuk membatasi jumlah koneksi TLS baru per detik dari satu sumber IP. Konfigurasikan batas waktu (timeout) yang agresif untuk proses TLS handshake yang belum selesai. Pertimbangkan penggunaan TLS fingerprinting untuk mendeteksi dan memblokir pola ClientHello yang mencurigakan.
Monitor secara aktif penggunaan memori pada seluruh server TLS. Siapkan alerting otomatis ketika RSS server melebihi ambang batas normal. Lakukan pemindaian versi OpenSSL pada seluruh infrastruktur dan pastikan tidak ada server yang menjalankan versi rentan.
Analisa Retasan
HollowByte mengungkapkan sebuah kelemahan fundamental dalam cara OpenSSL (dan banyak software network lainnya) menangani input dari klien. Dengan mempercayai deklarasi ukuran body dari ClientHello secara mentah-mentah, OpenSSL membiarkan penyerang mengontrol alokasi memori server dari jarak jauh. Ini bukan sekadar bug alokasi memori biasa, tetapi sebuah pelajaran tentang bahaya mempercayai input klien pada layer manapun dari stack protokol. OPENSSL_clear_realloc() yang seharusnya menjadi bentuk pertahanan justru menjadi titik masuk utama karena tidak ada validasi terhadap konsistensi antara ukuran yang dideklarasikan dan ukuran aktual data yang dikirim.
Dampak dari kerentanan ini melampaui sekadar server OpenSSL itu sendiri. Dalam ekosistem Indonesia di mana banyak ISP dan provider cloud masih menggunakan konfigurasi default, satu serangan HollowByte yang terkoordinasi dapat menyebabkan gangguan layanan simultan pada ratusan atau ribuan server. Pola serangan ini juga sangat sulit dideteksi karena payload yang dikirimkan sangat kecil (11 byte) dan terlihat seperti koneksi TLS ClientHello yang sah. Perbandingan dengan Slowloris sangat tepat, namun HollowByte jauh lebih efisien karena menargetkan cara memori dialokasikan dan dibebaskan, bukan hanya mempertahankan koneksi tetap terbuka.
Fakta bahwa perbaikan diklasifikasikan sebagai “hardening fix” dan bukan advisory CVE formal merupakan masalah keamanan siber tersendiri. Banyak organisasi, termasuk di Indonesia, bergantung pada CVE scoring dan advisory resmi untuk memprioritaskan patch management mereka. Tanpa CVE formal, pembaruan ini berisiko tertunda berbulan-bulan atau bahkan tahunan di banyak lingkungan production. Rekomendasi konkret untuk organisasi Indonesia: jangan tunggu CVE formal, segera verifikasi versi OpenSSL di seluruh infrastruktur dan terapkan pembaruan. Pastikan juga monitoring RSS pada server TLS dikonfigurasi dengan benar, sehingga anomali alokasi memori dapat dideteksi sebelum layanan benar-benar down.
Sumber: GBHackers – OpenSSL DoS Vulnerability
HollowByte, OpenSSL, DoS, Denial of Service, TLS Handshake, Memory Exhaustion, Okta Red Team, Heap Fragmentation, Slowloris, OOM, RSS, glibc
