HollowByte Bisa Bikin Memori Server OpenSSL Membengkak dengan Payload 11 Byte

Celah keamanan baru yang dijuluki HollowByte memungkinkan penyerang tanpa autentikasi memicu kondisi denial-of-service (DoS) pada server OpenSSL hanya dengan payload berbahaya berukuran 11 byte.

Masalah ini telah diperbaiki oleh tim OpenSSL tanpa penetapan identifier resmi, dan patch-nya juga sudah di-backport ke sejumlah rilis lama. Karena OpenSSL menjadi komponen dasar untuk komunikasi internet yang aman, organisasi disarankan memprioritaskan pembaruan library ke versi yang sudah diperbaiki.

HollowByte menjadi perhatian karena tekniknya relatif ringan dari sisi trafik, tetapi dapat membuat konsumsi memori server meningkat signifikan. Pada lingkungan tertentu, serangan ini bisa mengganggu ketersediaan layanan tanpa perlu bandwidth besar yang biasanya mudah terdeteksi oleh sistem monitoring.

Cara Kerja HollowByte pada TLS Handshake

Dalam proses TLS handshake, setiap pesan memiliki header 4 byte yang digunakan untuk mendeklarasikan ukuran pesan yang akan diterima. Pada implementasi OpenSSL yang rentan, server mengalokasikan memori berdasarkan ukuran yang diklaim di header sebelum payload benar-benar diterima dan divalidasi.

Setiap pesan TLS handshake diawali header yang berisi field panjang 3 byte. Field ini memberi tahu server berapa besar data handshake yang seharusnya mengikuti. Masalah muncul ketika server terlalu percaya pada klaim ukuran tersebut dan langsung mengalokasikan buffer sesuai angka yang dideklarasikan.

Penyerang dapat membuka koneksi TLS lalu mengirim input 11 byte yang menyatakan bahwa pesan berukuran jauh lebih besar akan menyusul. Worker thread kemudian menunggu data lanjutan yang tidak pernah datang, sementara alokasi memori sudah terjadi.

Dengan mengulangi proses ini pada banyak koneksi, penyerang dapat memaksa server mengalokasikan memori dalam jumlah besar menggunakan volume data yang kecil. Kondisi ini membuat HollowByte efektif sebagai vektor DoS terhadap layanan yang bergantung pada OpenSSL.

Memori Bisa Tetap Membengkak Setelah Koneksi Terputus

Dalam skenario normal, OpenSSL akan membebaskan buffer ketika koneksi terputus. Namun pada sistem yang menggunakan GNU C Library (glibc), alokasi kecil hingga menengah tidak selalu langsung dikembalikan ke sistem operasi. Memori tersebut dapat tetap disimpan untuk kemungkinan penggunaan ulang.

Penyerang dapat memperburuk kondisi ini dengan membuat gelombang koneksi yang menggunakan ukuran klaim acak. Pola tersebut mencegah allocator menggunakan ulang chunk memori yang sudah dibebaskan, sehingga heap menjadi sangat terfragmentasi.

Akibatnya, Resident Set Size (RSS) proses server dapat terus meningkat. Bahkan setelah penyerang memutus koneksi, proses server dapat tetap berada dalam kondisi memory bloat. Dalam kondisi seperti ini, restart proses menjadi cara utama untuk mengembalikan penggunaan memori secara penuh.

Dampak pada Server dan Aplikasi Populer

OpenSSL digunakan secara luas di berbagai komponen infrastruktur, termasuk web server seperti NGINX dan Apache, runtime bahasa pemrograman seperti Node.js, Python, Ruby, dan PHP, serta database seperti MySQL dan PostgreSQL. Library ini juga umum tersedia secara default di banyak distribusi Linux untuk enkripsi TLS dan pengelolaan sertifikat.

Dalam pengujian pada NGINX, lingkungan dengan kapasitas rendah dapat kehabisan memori dengan relatif mudah saat dieksploitasi menggunakan HollowByte. Pada server dengan spesifikasi lebih tinggi, konsumsi memori tetap dapat turun signifikan, bahkan hingga sekitar 25 persen, sementara bandwidth serangan masih berada di bawah ambang alert keamanan.

Walau celah DoS umumnya dianggap tidak separah kerentanan yang memungkinkan pencurian data atau eksekusi kode, dampaknya tetap serius. Gangguan layanan dapat memengaruhi operasional, reputasi, SLA, dan pengalaman pengguna, terutama pada layanan publik yang bergantung pada TLS.

Versi OpenSSL yang Sudah Diperbaiki

Perbaikan HollowByte telah tersedia di OpenSSL 4.0.1 dan di-backport ke versi 3.6.3, 3.5.7, 3.4.6, serta 3.0.21. Versi yang sudah diperbaiki mengubah perilaku alokasi buffer sehingga pertumbuhan buffer hanya dilakukan saat data benar-benar tiba, bukan semata-mata berdasarkan klaim ukuran pada header.

Meski perbaikan ini diperlakukan sebagai hardening fix dan bukan vulnerability security resmi, administrator tetap disarankan segera memperbarui paket OpenSSL melalui distribusi masing-masing. Sistem yang menjalankan layanan TLS terbuka ke internet perlu mendapat prioritas tertinggi.

Selain upgrade, tim infrastruktur juga sebaiknya memantau lonjakan RSS pada proses yang menggunakan OpenSSL, mengawasi pola koneksi TLS yang tidak wajar, dan meninjau konfigurasi timeout koneksi. Deteksi dini dapat membantu mencegah server masuk ke kondisi memori yang terus membengkak.