PyjriPyjri
pam
openssh
alpine
keamanan
security
vulnerability
ssh

Celah Password Bypass OpenSSH di Alpine

aaku tau kamu hebat
•
Celah Password Bypass OpenSSH di Alpine

PAM; Openssh; Alpine

1. Pengantar dan Konteks Singkat

Pada tanggal 5 November 2026, Alpine Linux merilis security advisory mengenai celah keamanan authentication bypass yang berdampak pada paket openssh-server. Celah ini memungkinkan penyerang jarak jauh (remote, unauthenticated attackers) untuk masuk ke sistem tanpa izin jika sistem menjalankan OpenSSH daemon (sshd) yang dikompilasi tanpa Pluggable Authentication Modules (PAM). Buat para system administrator dan DevOps engineer yang mengelola infrastruktur berbasis Alpine, masalah ini sangat perlu diwaspadai.

Sampai advisory ini diterbitkan pada 5 November 2026, belum ada nomor CVE (Common Vulnerabilities and Exposures) resmi yang ditetapkan. Jadi, tim infrastruktur disarankan untuk segera mengecek konfigurasi server masing-masing dan menerapkan langkah perbaikan yang ada.

2. Gambaran Teknis Ringkas

Celah keamanan ini terjadi akibat interaksi tak terduga antara build sshd tanpa dukungan PAM dan penanganan error standar pada fungsi crypt() milik C library musl.

Begini kronologinya:

  1. Saat memeriksa login password tanpa PAM, sshd akan meng-hash masukan password menggunakan fungsi crypt(), lalu membandingkan hasilnya dengan kredensial yang tersimpan di sistem.

  2. Akun sistem yang memang diset hanya untuk akses SSH key biasanya menyimpan satu karakter wildcard asterisk (*) pada field password di file shadow untuk mematikan akses password.

  3. Ketika sshd menerima masukan password berukuran sangat besar (oversized) untuk akun key-only ini, daemon akan "meminjam" salt dari akun lokal lain yang memiliki hash password berformat $5$ atau $6$.

  4. Masukan yang terlalu panjang tersebut menyebabkan fungsi crypt() pada musl gagal dan mengembalikan string error berupa satu karakter bintang (*).

  5. Karena sshd langsung membandingkan indikator error * tersebut dengan string * milik akun target, sistem menganggap proses verifikasi cocok dan berhasil. Akibatnya, penyerang langsung mendapatkan akses shell secara remote!

3. Kondisi Deployment Alpine vs Konteks Upstream

Untuk tahu apakah sistem kamu berdampak atau tidak, kita perlu memisahkan antara kondisi dari proyek upstream (OpenSSH) dan pengaturan bawaan (default) di Alpine Linux.

  • Konteks Upstream: Menurut Damien Miller dari proyek OpenSSH dan release notes OpenSSH 10.6p2, masalah ini secara spesifik hanya berdampak pada sistem Linux yang menggunakan musl libc dengan fitur PAM yang dimatikan. Sistem operasi non-Linux, distro Linux berbasis glibc, serta instance OpenSSH yang dikompilasi dengan dukungan PAM aktif tidak terdampak.

  • Kondisi Bawaan Alpine: Alpine Linux rentan secara default karena paket openssh-server resminya dibangun tanpa PAM, dan opsi PasswordAuthentication yes aktif secara bawaan. Banyak instalasi bawaan yang memiliki akun key-only berstatus *, termasuk konfigurasi root bawaan (sejak Alpine 3.16) dan user alpine pada image tiny-cloud. Walaupun setting bawaan PermitRootLogin prohibit-password mencegah login root secara langsung, penyerang yang berhasil menembus user alpine di image tiny-cloud bisa langsung menjalankan perintah doas tanpa password untuk menjadi root.

  • Kondisi yang Aman (Tidak Terdampak): Sistem kamu dipastikan aman jika memenuhi salah satu kondisi berikut:

    • Lingkungan kontainer (seperti Docker) yang tidak menjalankan proses sshd.

    • Host yang secara eksplisit dikonfigurasi dengan PasswordAuthentication no.

    • Sistem yang menjalankan openssh-server-pam dengan opsi UsePAM yes aktif.

    • Instance cloud yang di-deploy via cloud-init (karena otomatis menuliskan PasswordAuthentication no).

    • Akun yang terkunci dengan tanda seru (!) pada field password shadow.

    • Sistem yang tidak memiliki akun lokal dengan hash $5$ atau $6$.

4. Remediasi, Mitigasi, dan Kredit Penemuan

Ada dua cara utama yang bisa diambil untuk menutup celah ini: menginstal pembaruan paket openssh lalu menghentikan dan merestart daemon sshd secara manual, atau mematikan autentikasi password. Perlu diingat bahwa pembaruan paket tidak otomatis menggantikan daemon yang sedang berjalan; servis sshd wajib di-restart!

Jika pembaruan paket belum memungkinkan untuk segera dilakukan, kamu bisa menetapkan opsi PasswordAuthentication no pada konfigurasi SSH daemon (sshd_config) lalu melakukan restart pada servis tersebut.

Berikut adalah daftar versi perbaikan sesuai dengan cabang (branch) rilisnya:

BRANCH    VERSI FIXED     POINT RELEASE
---------------------------------------
edge      10.6_p2-r0      N/A
3.24      10.3_p1-r2      3.24.4
3.23      10.2_p1-r1      3.23.8
3.22      10.0_p1-r11     3.22.8
3.21      9.9_p2-r1       3.21.10
3.20      9.7_p1-r6       N/A
3.19      9.6_p1-r3       N/A
3.18      9.3_p2-r4       N/A
3.17      9.1_p1-r7       N/A
3.16      9.0_p1-r6       N/A

Celah keamanan ini ditemukan dan dilaporkan oleh Özgün Kültekin dari Wakefield. Selain itu, laporan dari The Hacker News mencatat bahwa belum ada laporan serangan aktif yang memanfaatkan celah ini pada saat publikasi dilakukan—pernyataan ini berasal dari penelusuran The Hacker News, bukan dari pengumuman resmi Alpine atau OpenSSH.

5. Kesimpulan & Diskusi Tim

Kasus ini jadi pengingat penting soal hardening keamanan bawaan di distro Linux yang minimalis. Mengunci autentikasi agar selalu menggunakan SSH key di seluruh infrastruktur produksi adalah garis pertahanan pertama yang sangat ampuh.

Diskusi

Login dulu buat ikutan diskusi.