Peneliti nemu bug aneh di musl libc: kirim password 257 karakter ke server Alpine Linux, dan root yang seharusnya terkunci malah bisa masuk. Ternyata si musl ganti NULL jadi '*' pas crypt() gagal, dan itu bikin hash cocok sama akun yang dikunci. Cuma musl tanpa PAM yang kena — glibc, OpenBSD, Dropbear aman.

Dulu zaman Unix tua, hash password cuma nongol di /etc/passwd yang bisa dibaca siapa aja. Tahun 1980, Bill Joy masukin karakter '*' buat akun daemon — artinya akun itu gak bisa login karena '*' bukan hash valid. Hingga sekarang Unix masih lakuin begitu, cuma hash-nya pindah ke /etc/shadow dan pakai format $6$abc$k2P9... yang artinya sha512 dengan salt abc.

Nah, musl libc (library C standar Alpine Linux) punya perilaku unik. Kalau crypt() gagal — misalnya salt minta algoritma yang gak didukung — musl gak return NULL seperti libc lain. Dia return satu karakter: '*'. Alasannya biar program gak crash pas compare hash. Tapi di sini mulai lucu: sha512crypt makin lama kalau password makin panjang. Jadi musl batasi maksimal 256 byte. Kirim password 257 byte? crypt() gagal, return '*'.

Kenapa '*' itu berbahaya buat akun terkunci

Di Alpine, akun root dikunci dengan hash '*' di /etc/shadow. Normalnya '*' artinya gak ada password yang cocok. Tapi kalau kamu kirim password 257 karakter, crypt() return '*' juga. Bandingannya jadi '*' sama '*' — cocok! Server bilang login berhasil padahal akun itu terkunci. Ini CVE-2019-5021 versi baru yang ditemukan lewat testing otomatis masif.

Peneliti nyoba build sshd pake berbagai kombinas: glibc, musl, dengan PAM, tanpa PAM, dengan shadow, tanpa shadow. Dia lempar 17.600 percobaan login aneh — hash rusak, akun rusak, password kepanjangan. Semua build sepakat hasilnya, kecuali satu: musl tanpa PAM. Itu aja yang bilang 'ya' buat login yang seharusnya ditolak.

Siapa yang kena dan siapa yang aman

Kalau kamu pakai Alpine Linux official image di AWS atau Azure, user default 'alpine' punya passwordless doas — berarti root access terbuka lewat bug ini. Tapi kalau Debian, Ubuntu, Fedora, atau distro lain pakai glibc? Aman. Pakai PAM? Aman. OpenBSD, Dropbear? Aman. Cuma musl tanpa PAM yang bolong. Kebanyakan distro lewat PAM jadi gak pernah panggil crypt() untuk '*', jadi bug ini nyembunyi lama.

Fakta ngejelin: bug ini cuma empat baris di bawah fix pick_salt() yang baru dipatch empat hari sebelum peneliti nemuin. Debian minta glibc copy behavior musl return '*', enam tahun kemudian pindah ke libxcrypt yang return '*0' — beda satu karakter doang. Peneliti bilang dia pakai 'agent swarms' buat testing, gak mau detailin. Tapi hasilnya jelas: musl tanpa PAM adalah satu-satunya yang vulnerable.

Apa yang harus kamu lakuin sekarang

Kalau server kamu jalan di Alpine Linux tanpa PAM (default Alpine), update musl libc ke versi terbaru yang udah patch batas 256 byte dan handling '*' yang benar. Atau aktifkan PAM buat sshd — itu paling gampang. Cek /etc/shadow, pastiin akun root gak cuma '*'. Dan ya, jangan percaya diri banget sama 'akun terkunci' kalau library C-nya punya quirk kayak gini.

Catatan redaksi

Kalau lo cuma ambil satu hal dari artikel ini

Peneliti nemu bug aneh di musl libc: kirim password 257 karakter ke server Alpine Linux, dan root yang seharusnya terkunci malah bisa masuk. Ternyata si musl ganti NULL jadi '*' pas crypt() gagal, dan itu bikin hash cocok sama akun yang dikunci. Cuma musl tanpa PAM yang kena — glibc, OpenBSD, Dropbear aman.

Alpine Linuxautentikasibugkeamananmusl