Skip to content

OpenSSH Password Authentication Bypass Hits Alpine Linux Servers Running sshd Without PAM

An OpenSSH password authentication bypass lets attackers into Alpine Linux servers running sshd without PAM through accounts with no password set. Fixed packages shipped on 5 November; no CVE has been assigned.

OpenSSH Password Authentication Bypass Hits Alpine Linux Servers Running sshd Without PAM

Alpine Linux servers that run sshd without PAM and allow password logins can be entered without a password, through an account that has none set. The flaw sits where OpenSSH meets the musl C library, and on an exposed server, Alpine's advisory of 5 November says, an attacker who reaches the SSH port "can log in without knowing any password". The same day OpenSSH shipped Portable OpenSSH 10.6p2, which blocks it inside sshd. No CVE identifier had been assigned when Alpine published.

How the bypass works

Without PAM, sshd checks a password by hashing it with crypt() and comparing the result with the stored entry. Alpine explains that musl's crypt() returns the string * as an error indicator when the key is over 256 bytes long. An account whose shadow entry is *, meaning no password at all, therefore matches any attempt that long. OpenSSH's notes say the bug "affects some Linux systems when built and run with PAM support disabled", and that the maintainers place the root cause outside sshd but changed sshd so it can't be exploited through it. Özgün Kültekin of Wakefield reported it.

Which machines are exposed

A server is open only when every condition in Alpine's list holds: sshd runs without PAM (the plain openssh-server package, or openssh-server-pam with UsePAM no), password logins are on, one account has * as its password field, and another account has a $5$ or $6$ hash. Root has shipped as root:* in the base image since about Alpine 3.16, though the default PermitRootLogin prohibit-password still protects root unless another account that can log in is able to become root. Official cloud images that carry the passwordless alpine user "become exploitable as soon as any $6$ hash exists on the machine".

Containers that don't run sshd, UsePAM yes setups and accounts locked with ! are listed as not affected.

Fixed packages and the workaround

Alpine says every release it checked, 3.21 through 3.24 and edge, is vulnerable, along with the unsupported 3.16 to 3.20. Alpine's fixed openssh builds are:

  • edge: 10.6_p2-r0
  • 3.24: 10.3_p1-r2
  • 3.23: 10.2_p1-r1
  • 3.22: 10.0_p1-r11
  • 3.21: 9.9_p2-r1

Fixed builds for 3.16 to 3.20 are in Alpine's table, and the 3.21.10, 3.22.8, 3.23.8 and 3.24.4 point releases include the fix; sshd needs a restart after the upgrade. A server that can't be updated yet should set PasswordAuthentication no and restart it. Admins should also search /var/log/messages for "Accepted password for" lines naming an account that has no password. Where such a login can't be ruled out, Alpine says to treat the machine as compromised.