Pihak penyerang mampu menyusup dan mengambil alih akun tanpa kata sandi, seperti akun yang hanya menggunakan kunci SSH, pada server Alpine Linux yang menjalankan paket openssh-server bawaan. Serangan ini hanya membutuhkan akses jaringan ke server target, nama akun pengguna yang sah tanpa kata sandi, serta input string kata sandi berukuran antara 257 hingga 1.024 bita.
Tim pengembang OpenSSH menetapkan celah ini pada tingkat keparahan kritis dan meluncurkan versi perbaikan 10.6p2 untuk memblokir eksploitasi tersebut. Distribusi Alpine juga telah menerbitkan paket pembaruan khusus bagi setiap rilis hingga versi 3.16. Kerentanan ini terjadi saat daemon OpenSSH (sshd) menjalankan verifikasi kata sandi tanpa antarmuka PAM, opsi autentikasi kata sandi aktif, serta terdapat minimal satu akun pengguna lain di sistem yang memiliki hash kata sandi terkonfigurasi. Paket openssh-server bawaan Alpine dirancang tanpa PAM dan mengaktifkan otentikasi kata sandi secara bawaan.
Kerentanan bersumber dari cara sshd berinteraksi dengan musl, pustaka standar bahasa C pada Alpine. Sistem non-Linux, distro Linux berbasis glibc, serta implementasi otentikasi kata sandi berbasis PAM dinyatakan aman dari dampak ini, sebagaimana dipaparkan oleh Damien Miller dari proyek OpenSSH. Miller mengimbau pengelola sistem rentan untuk menyetel PasswordAuthentication=no atau menonaktifkan layanan SSH. Otoritas keamanan mengonfirmasi belum ada laporan eksploitasi aktif di alam liar.
Berdasarkan penasihat keamanan resmi Alpine, peladen berada dalam kondisi rentan jika memenuhi empat parameter prasyarat teknis secara bersamaan. Penyerang memerlukan nama akun sasaran tanpa kata sandi. Keberadaan satu akun berkredensial kata sandi sudah cukup membuat akun tanpa sandi lainnya terekspos. Serangan dilaporkan berhasil pada setiap percobaan melalui satu koneksi tunggal. Akun tipikal yang umumnya dikonfigurasi tanpa kata sandi mencakup akun layanan bawaan, akun administratif khusus, serta profil yang hanya memakai SSH key.
Akun root secara bawaan tetap terlindungi berkat aturan PermitRootLogin prohibit-password, kecuali bila disetel PermitRootLogin yes. Namun, perlindungan ini dapat runtuh jika akun yang disusupi memiliki privilese eskalasi hak akses seperti melalui utilitas doas. Sebagai contoh, citra tiny-cloud versi 3.18.11 hingga 3.24.3 memberikan privilese eksekusi doas tanpa kata sandi kepada akun alpine. Citra tersebut awalnya aman, tetapi menjadi rentan begitu ada hash kata sandi berformat $6$ di dalam sistem, misalnya saat administrator menambahkan kata sandi konsol. Dalam kondisi tersebut, peretas dapat masuk ke akun alpine lalu menjalankan doas untuk mengambil alih hak akses root.
Sebaliknya, kontainer tanpa daemon sshd, sistem dengan konfigurasi eksplisit PasswordAuthentication no, serta instans komputasi awan berbasis cloud-init dinyatakan aman karena cloud-init menonaktifkan otentikasi kata sandi secara otomatis. Akun yang dikunci dengan tanda seru (!) pada /etc/shadow dan lingkungan tanpa format hash bertanda dolar ($) juga kebal.
Peneliti keamanan Özgün Kültekin dari Wakefield, pelapor pertama masalah ini, menyebut distribusi berbasis musl lain seperti OpenWrt, Buildroot, dan Yocto sebagai target potensial yang perlu dievaluasi. OpenWrt secara standar menggunakan paket Dropbear yang kebal dari masalah ini, sehingga bahaya hanya timbul apabila pengelola memasang paket openssh-server tambahan.
Pengguna Alpine disarankan memperbarui paket sistem dan memuat ulang layanan sshd, mengingat proses upgrade paket tidak otomatis memuat ulang daemon yang aktif di latar belakang. Pembaruan tersedia untuk rilis stabil 3.21.10, 3.22.8, 3.23.8, 3.24.4, hingga rilis lama dari cabang 3.16 sampai 3.21 yang telah melewati masa pemeliharaan resmi. Instans tiny-cloud versi terdahulu juga diwajibkan menerapkan tambalan atau memodifikasi konfigurasi. Bagi pengguna yang mengompilasi dari kode sumber, rilis OpenSSH 10.6p2 telah menyertakan perbaikan logika ini.
Jika pembaruan paket belum bisa diterapkan, mitigasi sementara dilakukan dengan mematikan otentikasi kata sandi. Sebelum menerapkannya, pastikan login menggunakan kunci SSH berfungsi normal dan pertahankan sesi terminal aktif. Ubah konfigurasi menjadi PasswordAuthentication no, uji keabsahan dengan perintah sshd -t, lalu muat ulang daemon sshd.
Panduan keamanan Alpine memuat instruksi penambahan berkas drop-in ke /etc/ssh/sshd_config.d (berlaku sejak versi 3.19 ke atas) serta perubahan nilai PasswordAuthentication dari yes menjadi no pada /etc/ssh/sshd_config, termasuk di dalam blok Match. Perubahan dapat diverifikasi dengan sshd -T | grep -i passwordauthentication yang wajib menghasilkan keluaran passwordauthentication no.
Pengelola juga diimbau memeriksa berkas /var/log/messages untuk menyisir entri log sshd berupa Accepted password pada akun tanpa sandi, seperti alpine, root, atau akun khusus SSH key. Jika terindikasi terekspos, pengelola disarankan meninjau riwayat eksekusi doas, akun pengguna baru, modifikasi berkas, dan penambahan kunci otentikasi. Penasihat resmi menegaskan bahwa jika ketiadaan aktivitas mencurigakan tidak dapat dipastikan, mesin harus dianggap telah disusupi sepenuhnya.
Mekanisme Teknis Sandi Panjang
Tanpa antarmuka PAM, daemon sshd memvalidasi kata sandi secara mandiri menggunakan fungsi crypt() bawaan pustaka C untuk mengomputasi hash tebakan pengguna, lalu membandingkannya dengan nilai yang tersimpan di basis data sistem. Pada akun tanpa sandi, field penyimpanan hash umumnya hanya berupa tanda bintang (*). Karena karakter tunggal tersebut tidak memiliki salt, sshd meminjam salt dari akun lain yang memiliki hash valid di berkas kredensial.
Ketika memproses format hash $5$ dan $6$, fungsi crypt() milik musl secara otomatis menolak string kata sandi yang melebihi 256 bita dan mengembalikan karakter tanda bintang (*) sebagai penanda kegagalan. Karena nilai kembalian tanda bintang tersebut cocok dengan nilai tanda bintang pada field akun tanpa sandi, sshd menganggap proses autentikasi berhasil. Batas maksimal panjang masukan ditentukan oleh kapasitas internal penyangga sshd hingga 1.024 bita.
Perilaku pustaka musl tersebut berakar dari modifikasi kode pada 9 Agustus 2012 yang dirancang agar kegagalan crypt() menghasilkan hash yang tidak valid alih-alih nilai NULL guna mencegah celah pada aplikasi yang tidak mengecek nilai eror. Batasan panjang 256 bita ditambahkan pada 29 Agustus 2012 untuk mencegah ancaman DoS. Sementara itu, mekanisme peminjaman salt diperkenalkan pada pembaruan OpenSSH tanggal 15 Juli 2016 guna menambal CVE-2016-6210 yang membocorkan validitas nama pengguna. Kültekin menjelaskan bahwa celah ini telah tertanam di dalam sistem sejak perubahan kode tersebut diterapkan.
Perbaikan pada OpenSSH versi 10.6p2 kini memerintahkan sshd untuk menolak autentikasi jika field penyimpanan kredensial berukuran kurang dari empat karakter. OpenSSH menyebut langkah ini sebagai mitigasi sementara (workaround) karena akar masalah berada di luar kendali basis kode sshd. Repositori paket Alpine juga menyertakan tambalan internal serupa.
Penerbitan Cepat Tanpa Embargo Panjang
Tim pengembang di bawah Damien Miller bergerak cepat merilis perbaikan tak lama setelah menerima laporan. Miller menyatakan timnya memandang masa embargo laporan kerentanan yang panjang berisiko tinggi dan menguntungkan pihak penyerang, terutama karena agen kecerdasan buatan (AI) kini mampu merekayasa ulang dan menemukan celah yang sama secara mandiri dalam hitungan jam. Belum ada kode pengenal CVE resmi yang dialokasikan untuk kerentanan ini saat berita diterbitkan.
