Celah OpenSSH dan musl Bikin Alpine Linux Bisa Dibobol Tanpa Password

Telset.id – Pengguna Alpine Linux dan sejumlah distribusi Linux lain menghadapi risiko keamanan serius setelah ditemukan kombinasi celah pada OpenSSH dan musl libc yang memungkinkan penyerang masuk ke sistem tanpa perlu memasukkan password yang benar. Cukup dengan mengetik lebih dari 256 karakter pada prompt password, penyerang bisa menembus sistem melalui celah yang dijuluki SSHhole tersebut. Kondisi ini menjadi perhatian besar karena Alpine Linux disebut sebagai pilihan default untuk apa yang bisa mencapai jutaan instalasi di container Docker, Kubernetes, Proxmox, server, cloud VM, hingga perangkat embedded.

Kombinasi kerentanan ini bekerja jika beberapa syarat terpenuhi secara bersamaan, yaitu OpenSSH, musl, autentikasi password yang tidak dinonaktifkan secara eksplisit, tidak menggunakan PAM, serta adanya satu user arbitrer dengan password yang diatur menggunakan hash SHA-512/256. Menurut laporan Tom’s Hardware, celah ini hadir—meski tidak selalu aktif—pada Buildroot, Yocto, dan Void Linux. OpenWRT sendiri menggunakan Dropbear untuk autentikasi secara default, tetapi pengguna dapat memasang OpenSSH sebagai gantinya.

Alpine Linux menjadi sorotan utama karena distribusi ini hadir dengan seluruh kondisi yang diperlukan dan autentikasi password aktif secara default, sehingga membutuhkan patch segera. Meski secara praktik mayoritas instalasi Alpine dan distribusi sejenis tidak dapat diakses langsung dari internet, siapa pun penyerang di dalam jaringan—termasuk jaringan korporat, home lab, jaringan cloud, dan VPN—dapat masuk dengan memanfaatkan celah ini. Hanya dibutuhkan satu akun pengguna valid, yang tidak terlalu sulit didapatkan di lingkungan korporat yang cukup besar, dan penyerang pun sudah berada di dalam jaringan. Pemindaian dan pengujian kerentanan ini disebut juga sangat mudah dilakukan.

Secara teknis, kekacauan ini terjadi ketika fungsi crypt() milik musl mengembalikan “*” sebagai kondisi error, bukan nilai null seperti konvensi umumnya, lalu OpenSSH menggunakannya untuk membandingkan dengan hash password—padahal seharusnya tidak. Input yang terlalu panjang kemudian memicu rangkaian kesalahan tersebut. Jika Anda pernah melihat file /etc/passwd atau /etc/shadow, tanda bintang tunggal biasanya menjadi placeholder untuk hash password pada akun tanpa password, yang berarti “tidak ada password yang seharusnya berhasil.”

OpenSSH telah menerbitkan perbaikan beserta catatan advisory, begitu pula penulis musl, Rich Felker. Kedua pihak tampak saling menyalahkan, tetapi dilihat dari luar, tanggung jawab tampaknya dibagi bersama. Situs SSHhole memuat seluruh detail mengenai kerentanan ini.

Langkah Mitigasi dan Patch Segera

Langkah mitigasi paling mudah adalah dengan menetapkan “PasswordAuthentication” menjadi “no” secara eksplisit pada file konfigurasi OpenSSH, lalu me-restart layanan tersebut. Bagi pengguna yang mengandalkan autentikasi password, patch menjadi keharusan. Sistem yang terdampak disarankan segera diperbarui mengikuti catatan advisory dari proyek terkait.

Ancaman semacam ini menunjukkan bahwa celah pada lapisan autentikasi tetap menjadi pintu masuk favorit bagi penyerang. Sebelumnya, dunia keamanan juga dihebohkan oleh temuan bahwa AI worm disebut bisa mereplikasi diri tanpa datacenter, menandakan lanskap ancaman siber yang terus berkembang dan menuntut kewaspadaan berlapis dari para pengelola infrastruktur.

Bagi tim yang mengelola infrastruktur berbasis container atau cloud, memastikan konfigurasi autentikasi tidak menggunakan default yang rentan menjadi langkah awal yang krusial. Pemeriksaan menyeluruh terhadap konfigurasi OpenSSH dan pemantauan akses jaringan internal perlu dilakukan untuk menutup celah sebelum dieksploitasi.

Kerentanan ini juga menjadi pengingat bahwa ketergantungan pada pustaka dasar seperti musl libc dapat membawa implikasi luas. Ketika satu fungsi mengembalikan nilai yang tidak sesuai konvensi, dampaknya bisa merambat ke lapisan autentikasi yang seharusnya menjadi benteng utama sistem. Pengelola sistem disarankan tidak menunda pembaruan, terutama pada instalasi yang menggunakan autentikasi password dan tidak memakai PAM.

Dengan patch yang sudah tersedia dari OpenSSH dan musl, langkah pemulihan kini berada di tangan para pengelola sistem. Prioritas utama adalah memastikan setiap instalasi Alpine Linux dan distribusi terkait segera diperbarui, sekaligus menonaktifkan autentikasi password bila tidak diperlukan, agar celah SSHhole tidak menjadi pintu masuk yang terbuka lebar bagi penyerang di dalam jaringan.