Pihak penyerang mampu menyusup ke dalam akun tanpa kata sandi, seperti akun berbasis kunci otentikasi SSH, pada server Alpine Linux yang mengoperasikan paket openssh-server standar bawaan. Dalam melancarkan aksinya, peretas hanya membutuhkan akses jaringan langsung menuju target, mengetahui nama akun sasaran, dan memasukkan kata sandi dengan panjang karakter antara 257 hingga 1.024 bita.

Pengembang OpenSSH, yang mengategorikan celah keamanan ini pada level kritis, telah merilis versi 10.6p2 untuk memblokir ancaman tersebut. Bersamaan dengan itu, tim pengelola Alpine Linux telah mendistribusikan perbaikan paket untuk seluruh versi rilis mereka hingga versi 3.16.

Mekanisme serangan terjadi ketika daemon OpenSSH (sshd) memproses verifikasi kata sandi secara mandiri tanpa Pluggable Authentication Module (PAM), login kata sandi dalam kondisi aktif, serta terdapat sekurang-kurangnya satu akun lain di sistem yang memiliki kata sandi aktif. Paket openssh-server bawaan Alpine dikompilasi tanpa dukungan PAM, dan opsi login kata sandi aktif secara bawaan.

Kerentanan bersumber dari interaksi antara sshd dan musl, pustaka standar C yang mendasari Alpine Linux. Platform non-Linux, distribusi Linux berbasis glibc, serta infrastruktur yang menjalankan pemeriksaan kata sandi melalui antarmuka PAM tidak terpengaruh, jelas Damien Miller dari proyek OpenSSH.

Miller memperingatkan pengelola server terdampak untuk mengatur PasswordAuthentication=no atau menonaktifkan SSH segera. Hingga rilis perbaikan diterbitkan, belum ditemukan adanya laporan insiden nyata yang mengeksploitasi kelemahan ini.

Peringatan keamanan resmi Alpine mencantumkan empat prasyarat utama yang membuat server rentan jika terpenuhi bersamaan: sshd berjalan tanpa modul PAM, PasswordAuthentication bernilai yes, terdapat akun tanpa sandi, serta ada akun lain yang memiliki hash kata sandi aktif di berkas shadow. Peretas wajib mengetahui nama akun tanpa sandi tersebut. Keberadaan satu akun lain bersandi sudah cukup untuk mengekspos semua akun tanpa sandi, dan eksploitasi dapat berhasil pada setiap percobaan melalui koneksi tunggal.

Di Alpine, profil akun tanpa konfigurasi kata sandi mencakup akun yang dibuat tanpa sandi lewat adduser -D, akun yang diproteksi hanya dengan SSH key, serta akun bawaan pada citra tiny-cloud resmi versi sebelum 3.24.4 yang belum pernah dipasangi kata sandi.

Akun root terlindungi secara bawaan lewat pengaturan PermitRootLogin prohibit-password dan hanya bisa diakses langsung jika konfigurasi diubah ke PermitRootLogin yes. Namun, proteksi bawaan tidak berdaya bila akun yang berhasil disusupi memiliki wewenang eskalasi hak akses administratif, semisal lewat utilitas doas.

Citra tiny-cloud rilis 3.18.11 hingga 3.24.3 memberikan wewenang doas tanpa sandi kepada akun bawaan alpine. Citra tersebut aman saat pertama kali dinyalakan, tetapi menjadi rentan setelah terdapat hash sandi bertipe $6$ di sistem, misalnya usai administrator menyetel kata sandi konsol. Peretas dapat masuk sebagai akun alpine lalu memanfaatkan doas untuk menjadi root.

Kontainer yang tidak menjalankan daemon sshd, sistem dengan parameter PasswordAuthentication no, serta citra awan yang memakai konfigurasi cloud-init (yang otomatis mematikan opsi login sandi) terhindar dari dampak celah ini. Akun yang terkunci dengan tanda seru (!) di berkas /etc/shadow juga aman, begitu pula sistem yang tidak menyimpan entri hash sandi berformat tanda dolar ($).

Cakupan kelemahan ini meluas ke luar ekosistem Alpine. Peneliti keamanan Özgün Kültekin dari Wakefield, pelapor pertama celah ini, menyebut sistem OpenWrt, Buildroot, dan Yocto sebagai target berbasis musl yang wajib diperiksa. OpenWrt sendiri menggunakan Dropbear secara baku, yang dipastikan Kültekin tidak terpengaruh, kecuali jika pengelola memasang paket OpenSSH server tambahan.

Bagi pengguna Alpine, perbaikan menuntut pembaruan paket dan memulai ulang layanan sshd karena pembaruan repositori semata tidak menghentikan proses sshd yang sedang berjalan. Rilis berkala 3.21.10, 3.22.8, 3.23.8, dan 3.24.4 sudah menyertakan paket perbaikan. Cabang versi 3.16 hingga 3.21 yang telah melewati masa dukungan resmi juga menerima paket pembaruan. Seluruh instans awan berbasis tiny-cloud yang lebih lawas wajib memperbarui sistem atau mematikan otentikasi kata sandi. Bagi pengguna yang mengompilasi kode sumber secara mandiri, versi 10.6p2 telah memuat perbaikan logika tersebut.

Jika pembaruan paket belum memungkinkan, mematikan otentikasi berbasis kata sandi merupakan metode alternatif. Pastikan otentikasi login SSH key bekerja dan pertahankan sesi yang aktif sebelum menerapkan PasswordAuthentication no. Jalankan perintah sshd -t untuk memvalidasi sintaks sebelum me-restart daemon sshd. Surat edaran peringatan menyertakan instruksi menyuntikkan konfigurasi ke drop-in /etc/ssh/sshd_config.d (yang dibaca sejak Alpine 3.19) dan mengubah nilai yes menjadi no pada berkas /etc/ssh/sshd_config. Perintah sshd -T | grep -i passwordauthentication harus menghasilkan keluaran passwordauthentication no.

Administrator diimbau memeriksa catatan /var/log/messages guna melacak baris sshd bertuliskan Accepted password pada akun tanpa sandi, seperti akun alpine, root, atau akun khusus SSH key. Jika server sempat terbuka terhadap ancaman, lakukan audit ekstra pada histori perintah doas, riwayat pendaftaran akun baru, berkas mencurigakan, dan berkas authorized keys. Jika riwayat mencurigakan tidak dapat dikesampingkan, perlakukan peladen tersebut sebagai sistem yang telah disusupi.

Mengapa Kata Sandi Panjang Menembus Sistem

Tanpa antarmuka PAM, komponen sshd memverifikasi masukan sandi secara mandiri menggunakan fungsi crypt() untuk mengomparasikan hash masukan dengan data di sistem. Akun pengguna tanpa sandi hanya menyimpan karakter bintang (*) pada berkas otentikasi. Format tersebut terlalu ringkas untuk menampung nilai salt, sehingga sshd meminjam nilai salt milik profil pengguna lain yang memiliki hash sandi sah.

Pada tipe algoritma hash $5$ dan $6$, fungsi crypt() pada pustaka musl menolak masukan sandi yang melebihi ukuran 256 bita dan mengembalikan respons karakter bintang (*). Respons kesalahan berupa bintang (*) tersebut seketika cocok dengan karakter bintang (*) pada data akun tanpa sandi, sehingga sshd menganggap otentikasi sukses. Batas panjang masukan dibatasi oleh kapasitas internal sshd maksimal 1.024 bita.

Perilaku ini bermula dari perubahan kode pustaka musl pada 9 Agustus 2012 yang membuat kegagalan crypt() mengembalikan non-NULL unmatchable hash demi menangani perangkat lunak yang lalai memeriksa status kegagalan. Batasan panjang 256 bita ditambahkan pada 29 Agustus 2012 untuk mencegah serangan denial-of-service. Mekanisme peminjaman komponen salt akun lain bermula dari tambalan CVE-2016-6210 pada OpenSSH tertanggal 15 Juli 2016. Kültekin mengungkap bahwa celah bypass sandi panjang ini sebenarnya telah bersemayam sejak perubahan tersebut.

Perbaikan internal pada versi 10.6p2 memerintahkan sshd menolak kecocokan kata sandi jika kolom penyimpanan sandi kurang dari empat karakter. Manajemen OpenSSH melabeli solusi ini sebagai penanganan sementara karena pangkal permasalahan berada di luar kode sshd. Rilisan paket Alpine kini memuat tambalan khusus untuk menuntaskannya.

Alasan Perbaikan Diterbitkan Dalam Satu Hari

Divisi pengembang yang dipimpin Damien Miller menerima laporan celah ini pada awal pekan dan langsung meluncurkan berkas perbaikan secepatnya. Miller mengungkapkan bahwa masa embargo kerentanan yang terlalu lama berbahaya dan menguntungkan penyerang, terlebih agen kecerdasan buatan (AI) kini mampu menemukan kembali celah serupa dalam hitungan jam. Belum ada nomor registrasi CVE resmi yang dialokasikan untuk celah ini.