Penyerang dapat masuk ke akun yang tidak memiliki kata sandi, seperti akun pengguna yang hanya menggunakan kunci SSH publik, pada peladen Alpine Linux yang menjalankan openssh-server bawaan. Penyerang hanya membutuhkan akses jaringan ke peladen, mengetahui nama akun yang valid, serta mengirimkan kata sandi dengan panjang antara 257 hingga 1.024 bita.
Pengembang OpenSSH menilai kerentanan ini sangat kritis dan telah merilis OpenSSH 10.6p2 untuk menutup celah tersebut. Tim Alpine Linux juga memublikasikan paket perbaikan untuk setiap rilis yang didukung hingga versi 3.16.
Bypass ini terjadi ketika daemon OpenSSH (sshd) memeriksa kata sandi tanpa memanfaatkan perantara antarmuka Pluggable Authentication Module (PAM), pengaturan otentikasi kata sandi aktif, dan setidaknya ada satu akun lain di sistem yang memiliki kata sandi aktif. Paket openssh-server bawaan di Alpine dikompilasi tanpa PAM, dan fitur otentikasi kata sandi dibiarkan menyala secara baku.
Celah ini berasal dari cara sshd berinteraksi dengan pustaka C musl yang mendasari Alpine Linux. Sistem operasi non-Linux, sistem Linux berbasis glibc, serta platform yang memvalidasi kata sandi melalui PAM tidak terpengaruh oleh masalah ini, jelas Damien Miller dari proyek OpenSSH.
Miller mengimbau administrator yang menjalankan sistem terdampak untuk segera menyetel konfigurasi PasswordAuthentication=no atau menonaktifkan SSH secepatnya. Hingga kini, belum ditemukan adanya eksploitasi aktif di dunia nyata.
Berdasarkan penasihat keamanan Alpine Linux, terdapat empat prasyarat teknis yang membuat sebuah peladen rentan apabila terpenuhi secara bersamaan:
Penyerang juga harus mengetahui nama akun yang tidak memiliki sandi. Keberadaan satu akun lain yang memiliki kata sandi sudah cukup untuk membuat akun tanpa sandi rentan dibobol. Penyerangan selalu berhasil dalam satu kali percobaan koneksi tunggal.
Di Alpine Linux, akun-akun yang umumnya tidak memiliki kata sandi meliputi:
Akun administratif Root secara baku terlindungi karena opsi PermitRootLogin prohibit-password aktif, sehingga akses root via jaringan hanya mungkin jika diubah manual menjadi PermitRootLogin yes. Namun, pengamanan ini tidak berguna jika akun pengguna biasa yang berhasil ditembus memiliki hak eskalasi root melalui utilitas seperti doas.
Citra tiny-cloud dari rilis 3.18.11 hingga 3.24.3 memberikan akses doas tanpa sandi kepada akun bawaan alpine. Citra ini awalnya aman saat pertama kali di-boot, tetapi langsung rentan begitu sistem memiliki hash bertipe $6$, misalnya setelah pengelola membuat kata sandi untuk konsol lokal. Penyerang dapat masuk sebagai alpine lalu mengeksekusi doas untuk mengambil alih hak akses root.
Wadah kontainer yang tidak menjalankan sshd, sistem dengan konfigurasi PasswordAuthentication no, serta citra cloud yang dibuat via cloud-init yang menonaktifkan sandi, dipastikan aman. Akun yang dikunci dengan tanda seru ! di /etc/shadow dan sistem tanpa satu pun akun berformat hash bertanda $ juga tidak terpengaruh.
Celah ini tidak terbatas pada Alpine Linux saja. Özgün Kültekin dari Wakefield, peneliti yang menemukan celah ini, menyebut proyek OpenWrt, Buildroot, dan Yocto sebagai sistem berbasis musl lain yang perlu diperiksa oleh pengelola.
OpenWrt secara bawaan menggunakan Dropbear untuk sambungan SSH, dan Kültekin memastikan Dropbear tidak terdampak. Kerentanan pada OpenWrt baru menjadi ancaman nyata jika administrator secara sengaja menginstal dan menjalankan OpenSSH.
Pengguna Alpine Linux diinstruksikan untuk segera memperbarui paket dan memuat ulang layanan, karena pembaruan paket tidak otomatis me-restart daemon sshd yang sedang berjalan:
Pembaruan versi 3.21.10, 3.22.8, 3.23.8, dan 3.24.4 telah menyertakan perbaikan. Cabang versi lawas mulai 3.16 hingga 3.21 yang sudah melewati akhir masa dukungan juga tetap menerima pembaruan tambalan darurat ini.
Instansi komputasi awan berbasis citra tiny-cloud versi lama wajib segera diperbarui atau menerapkan penyesuaian konfigurasi penonaktifan kata sandi.
Bagi pengguna yang mengompilasi OpenSSH secara mandiri dari kode sumber, rilis OpenSSH 10.6p2 telah mencakup seluruh tambalan perbaikan tersebut.
Jika pembaruan paket belum dapat dilakukan, menonaktifkan login kata sandi efektif menutup celah ini. Pastikan login berbasis kunci SSH berfungsi dengan baik dan pertahankan sesi terminal tetap terbuka sebelum mengubah pengaturan. Ubah baris menjadi PasswordAuthentication no, uji berkas konfigurasi dengan perintah sshd -t, lalu muat ulang layanan sshd.
Panduan keamanan menyediakan perintah untuk menyetel konfigurasi drop-in di /etc/ssh/sshd_config.d, yang menjadi standar sejak Alpine 3.19. Panduan ini juga menyarankan pengubahan setiap entri PasswordAuthentication di /etc/ssh/sshd_config dari yes menjadi no, termasuk di blok Match. Pastikan luaran perintah sshd -T | grep -i passwordauthentication menunjukkan passwordauthentication no.
Pengelola server disarankan memeriksa berkas /var/log/messages untuk mencari catatan sshd mencurigakan yang berbunyi Accepted password pada akun tanpa sandi, seperti alpine, root, atau akun khusus kunci kriptografi. Jika sistem sempat terekspos, periksa riwayat doas, akun pengguna baru, berkas mencurigakan, dan berkas authorized keys.
Bila tidak dapat memastikan status keamanannya, pengelola disarankan untuk menganggap peladen telah berhasil disusupi.
Mengapa Penggunaan Kata Sandi Panjang Bisa Bekerja
Tanpa modul PAM, sshd memverifikasi kata sandi secara mandiri menggunakan fungsi crypt() bawaan pustaka C untuk menghasilkan hash dari input dan mencocokkannya dengan rekaman sistem.
Akun tanpa kata sandi biasanya memuat karakter * pada kolom autentikasinya. String tunggal ini tidak memuat salt unik, sehingga mekanisme sshd meminjam salt dari akun lain di sistem yang memiliki hash asli.
Pada hash $5$ dan $6$, fungsi crypt() milik pustaka musl menolak kata sandi yang lebih panjang dari 256 bita dan mengembalikan string *. Karakter * hasil galat ini cocok dengan * pada rekaman akun korban, sehingga sshd menganggap autentikasi berhasil dan mengizinkan login. Batas panjang masukan ini dibatasi oleh limit internal sshd sebesar 1.024 bita.
Perilaku pada musl ini berakar dari perubahan kode tanggal 9 Agustus 2012, di mana kegagalan crypt() diubah agar menghasilkan hash yang tidak cocok alih-alih NULL. Batas panjang 256 bita kemudian ditambahkan pada 29 Agustus 2012 guna mencegah serangan kelebihan beban (DoS).
Sementara itu, peminjaman salt dari akun lain berasal dari pembaruan OpenSSH tanggal 15 Juli 2016 untuk memitigasi CVE-2016-6210 terkait enumerasi nama pengguna. Kültekin menjelaskan bahwa kelemahan komparasi ini telah ada di sistem sejak perubahan tersebut diterapkan.
Perbaikan pada OpenSSH 10.6p2 kini menolak verifikasi jika hash tersimpan lebih pendek dari empat karakter. OpenSSH menyebut langkah ini sebagai mitigasi sementara (workaround) dan menegaskan akar masalah berada di luar rancangan sshd. Paket pembaruan repositori Alpine Linux juga telah menyertakan tambalan untuk mengatasi masalah ini.
Alasan Perbaikan Diterbitkan Hanya Berselang Satu Hari
Tim pengembang yang dipimpin oleh Damien Miller baru menerima laporan celah ini pada awal pekan dan langsung merilis pembaruan secepat mungkin. Miller menegaskan bahwa masa embargo kerentanan yang panjang berbahaya dan menguntungkan penyerang, terutama karena agen kecerdasan buatan (AI) kini mampu menemukan bug serupa secara mandiri hanya dalam hitungan jam.
Hingga pengumuman disiarkan, belum ada nomor CVE resmi yang dialokasikan untuk kerentanan ini.
