Skip to content
[ root@retasan:~# Saturday, Aug 29, 2026 ]

> Retasan.id_

// Portal Berita Keamanan Siber Terkini

  • Kebijakan & Privasi
  • Kontak Retasan.id
  • Tentang Retasan.
Exploit Development Malware Kebijakan Keamanan Cyberwarfare Tools Data Breach Video Catatan Pribadi Iklan Tutorial
Exploit Development

HollowByte: Kerentanan OpenSSL yang Membekukan Memori Server Hanya dengan 11 Byte TLS

// by retasan-news July 17, 2026 5 min read
HollowByte Kerentanan OpenSSL Membekukan Memori Server

Okta Red Team menemukan kerentanan baru dalam OpenSSL yang memungkinkan penyerang membekukan memori server hanya dengan mengirim 11 byte TLS ClientHello palsu. Kerentanan ini, yang dijuluki “HollowByte,” tidak memiliki CVE karena OpenSSL mengklasifikasikannya sebagai perbaikan bug atau hardening semata. Namun dampaknya terhadap ketersediaan server nyata dan dapat dieksploitasi tanpa autentikasi apa pun.

APA YANG TERJADI?

Okta Red Team menemukan bahwa OpenSSL versi 3.0 ke atas memiliki kerentanan pada path TLS ClientHello. Penyerang hanya perlu mengirim handshake yang menyatakan body sebesar 131KB melalui field `msg_body` dalam struktur `PACKET`, namun body tersebut tidak pernah benar-benar dikirimkan. Akibatnya, OpenSSL mengalokasikan buffer berdasarkan klaim ukuran tersebut dan mempertahankannya di memori secara permanen karena kode cleanup tidak pernah terpicu. Server menghabiskan ratusan megabyte memori hanya untuk menangani satu koneksi palsu.

Tim peneliti berhasil melakukan OOM-kill terhadap server 1GB dengan hanya 38 koneksi, di mana 547MB terisi oleh buffer yang membeku. Server 16GB kehilangan 25% dari total memori. Yang lebih menakutkan, glibc mempertahankan freed chunks untuk optimasi alokasi, sehingga fragmentasi heap terjadi secara permanen bahkan setelah koneksi ditutup. Kerentanan ini juga berlaku pada path DTLS yang belum diperbaiki hingga saat ini.

DETAIL TEKNIS

Mekanisme serangan dimulai dari implementasi DTLS di OpenSSL. Saat menerima ClientHello, OpenSSL mengurai konten handshake menggunakan macro `PACKET` untuk mendefinisikan rentang byte. Field `msg_body` dalam struktur `ssl_st` menyimpan referensi ke body pesan. Masalah terjadi ketika server mengalokasikan buffer berdasarkan ukuran yang dideklarasikan dalam header, namun attacker tidak pernah mengirim payload aktualnya. Karena tidak ada mekanisme timeout yang agresif untuk menunggu body yang hilang, buffer tersebut tetap teralokasi.

OpenSSL memperbaiki masalah ini dalam rilis 4.0.1, 3.6.3, 3.5.7, 3.4.6, dan 3.0.21 yang dirilis pada 9 Juni 2026. Perbaikan terdapat pada pull request 30792, 30793, dan 30794. Namun, path DTLS belum ditangani dalam patch ini. Kerentanan ini juga memiliki keterkaitan silang dengan CVE-2025-66199 (TLS 1.3 certificate-compression bug) dan CVE-2026-34183 (QUIC PATH_CHALLENGE), yang menunjukkan pola kerentanan serupa pada parsing handshake OpenSSL.

Yang kritis, OpenSSL tidak mengajukan CVE untuk kerentanan ini dan mengklasifikasikannya sebagai “bug or hardening only fix.” Klasifikasi ini berpotensi membuat banyak administrator tidak menyadari urgensi penerapan patch karena tidak muncul dalam vulnerability scanner berbasis CVE.

DAMPAK TERHADAP INDONESIA

Indonesia memiliki ketergantungan besar terhadap OpenSSL dalam infrastruktur web server, API gateway, dan layanan cloud lokal. Server-government.go.id, layanan perbankan digital, dan platform e-commerce besar kemungkinan menggunakan OpenSSL sebagai library TLS utama. Serangan HollowByte sangat mudah dilakukan — hanya membutuhkan satu script Python untuk mengirim ClientHello palsu — sehingga dapat digunakan oleh penyerang dengan kemampuan teknis rendah untuk melakukan denial of service terhadap layanan kritis.

Karena tidak ada CVE, vulnerability scanner komersial seperti Nessus dan Qualys kemungkinan belum memiliki plugin deteksi untuk kerentanan ini. Tim SOC di Indonesia harus secara aktif memeriksa versi OpenSSL yang digunakan dan memverifikasi patch secara manual. Pemerintah melalui BSSN dan Kementerian Kominfo sebaiknya mengeluarkan advisory khusus untuk memastikan lembaga negara menerapkan patch OpenSSL terbaru.

REKOMENDASI MITIGASI

Perbarui OpenSSL ke versi minimal 3.0.21 untuk branch 3.0, atau versi terbaru untuk branch lainnya. Jalankan perintah `openssl version` untuk memverifikasi versi yang terinstall. Monitor penggunaan memori server secara proaktif dan atur alerting untuk anomali alokasi memori yang tidak wajar. Implementasikan rate limiting pada TLS handshake untuk membatasi dampak serangan. Untuk layanan yang menggunakan DTLS, pertimbangkan untuk mematikan fitur tersebut atau mengganti dengan implementasi TLS 1.3 yang lebih aman. Audit seluruh dependency OpenSSL dalam supply chain perangkat lunak dan firmware yang digunakan oleh organisasi.

Analisa Retasan

HollowByte mengungkap kerentanan fundamental dalam cara OpenSSL menangani TLS handshake yang tidak lengkap. Root cause-nya terletak pada asumsi desain yang salah: OpenSSL mempercayai deklarasi ukuran dalam ClientHello tanpa menerapkan batas waktu atau batas alokasi yang ketat untuk body yang dijanjikan. Ini bukan sekadar bug implementasi, melainkan deficiency dalam defensive design yang seharusnya mempertahankan prinsip “never trust the client” di level protokol.

Ketiadaan CVE semakin memperburuk situasi karena banyak organisasi Indonesia mengandalkan CVE database sebagai satu-satunya sumber advisory keamanan.

Pola serangan ini menunjukkan kemiripan struktural dengan CVE-2025-66199 pada TLS 1.3 certificate compression dan CVE-2026-34183 pada QUIC PATH_CHALLENGE. Ketiganya mengeksploitasi bagaimana OpenSSL memproses variabel-length fields dalam handshake messages. Ini menunjukkan bahwa attack surface OpenSSL pada parsing handshake memerlukan audit menyeluruh yang melampaui pendekatan bug-by-bug.

Pola serupa juga ditemukan diimplementasi TLS lain seperti NSS (Mozilla) dan BoringSSL (Google), sehingga dampak potensial bisa lebih luas dari OpenSSL saja.

Bagi Indonesia, kerentanan ini menjadi pengingat bahwa dependency chain dalam infrastruktur digital sangat rapuh. Open source library seperti OpenSSL diandalkan oleh jutaan server di seluruh dunia, namun mekanisme pengamanannya sangat bergantung pada ketersediaan tim maintainer yang terbatas. Organisasi Indonesia harus mengadopsi Software Bill of Materials (SBOM) dan membangun capability untuk memverifikasi keamanan dependency secara independen, termasuk kemampuan untuk mem-patch OpenSSL tanpa menunggu rilis dari distro Linux. Investasi dalam memory profiling tools seperti Valgrind dan AddressSanitizer untuk memantau alokasi memori server produksi juga menjadi langkah preventif yang kritis.

Sumber: The Hacker News — OpenSSL HollowByte Flaw Could Freeze Servers with 11 Bytes

Tags: OpenSSL HollowByte, CVE-free vulnerability, TLS denial of service, memory fragmentation, glibc heap, server security, Okta Red Team, DTLS bypass

Tags: DTLS Bypass HollowByte Memory Fragmentation Okta Red Team OpenSSL Server Security TLS Denial of Service
Share:

retasan-news

← Previous Autonomi Militer dan Tantangan Infrastruktur Informasi Tepercaya di Era AI
Next → ViteVenom: 7 Paket npm Berbahaya Gunakan Blockchain C2 untuk Distribusikan RAT

Artikel Terkait

ShieldBreak: Bypass Lengkap terhadap Patch CVE-2026-50656 (RoguePlanet) pada Microsoft Defender

ShieldBreak: Bypass Lengkap terhadap Patch CVE-2026-50656 (RoguePlanet) pada Microsoft Defender

August 12, 2026
Serangan CSS pada Webmail: Celah Baru bagi AI Email Tools untuk Mencuri Token dan Membajak Sesi

Serangan CSS pada Webmail: Celah Baru bagi AI Email Tools untuk Mencuri Token dan Membajak Sesi

August 10, 2026
GDID: Pengidentifikasi Perangkat Global Windows yang Mengancam Privasi

GDID: Pengidentifikasi Perangkat Global Windows yang Mengancam Privasi

July 25, 2026

> leave_comment_

Your email address will not be published. Required fields are marked *

Copyright © 2026 Retasan | retasan.my.id

  • Kebijakan & Privasi
  • Kontak Retasan.id
  • Tentang Retasan.