OpenSSH Flaw Allows Password Authentication Bypass on Alpine Linux
A critical vulnerability in OpenSSH 10.6p2, when combined with specific Alpine Linux configurations using musl libc without PAM, allows remote attackers to bypass password authentication.
A critical flaw discovered in Portable OpenSSH version 10.6p2, in conjunction with certain Alpine Linux configurations, presents a significant risk by enabling remote attackers to bypass password authentication. This vulnerability specifically affects Linux systems that utilize musl libc and have PAM authentication disabled. The exploit requires a specific setup where an account has an asterisk ('*') in its password field, and another local account possesses a password hash starting with '$5$' or '$6$'. When these conditions are met, an attacker can authenticate to the system with a single connection, provided they know an account name and can reach the SSH port.
Alpine Linux has addressed the issue by releasing patched packages for multiple versions of its operating system, urging administrators to update their systems and restart the sshd service immediately. The vulnerability stems from an interaction between OpenSSH and musl's crypt() function. In environments without PAM, sshd hashes the submitted password and compares it to the stored password field. For accounts with an asterisk in their password field, sshd borrows the salt from another account. The critical trigger occurs when a submitted password exceeds 256 bytes; musl's password-hashing code then rejects it and returns an asterisk as an error marker. This marker coincidentally matches the target account's stored field, leading to a successful authentication instead of a rejection.
Researchers have identified that passwords between 257 and 1024 bytes can trigger this bypass on vulnerable systems. The actual content of the password is irrelevant; its length is the key factor in exploiting the flaw. This behavior is a result of how musl handles errors in its password-hashing function, returning a marker that aligns with the account's configuration. The vulnerability is a confluence of several factors: OpenSSH's use of '*' for accounts without usable passwords, musl's specific error handling that returns '*' as a marker, and OpenSSH's borrowed-salt mechanism.
Alpine's standard openssh-server package, which does not use PAM, is susceptible. However, systems configured with openssh-server-pam and 'UsePAM yes' are unaffected. Similarly, containers that do not run an SSH server are not exposed. The disclosure follows earlier security fixes for OpenSSH 10.6, but this particular issue targets password checks rather than encryption mechanisms. No CVE identifier had been assigned at the time of Alpine's advisory, highlighting the urgency for users to apply patches.
Exploitation requires an attacker to know a valid account name and have network access to the SSH port. The vulnerability can be chained with other misconfigurations. For instance, Alpine's default tiny-cloud images, from versions 3.18.11 through 3.24.3, contain an 'alpine' account with passwordless 'doas' access. If a qualifying password hash is added to another local account on such a system, an attacker could potentially log in as the 'alpine' user and gain root privileges, bypassing standard password authentication.
Administrators are strongly advised to apply the provided patches by running 'apk upgrade -U -a' followed by 'rc-service sshd restart'. Simply updating the package is insufficient, as the old daemon process must be restarted to load the patched code. For systems where immediate patching is not feasible, the recommended workaround is to disable password authentication entirely by setting 'PasswordAuthentication no' in the SSH server configuration, ensuring key-based access is functional, and then restarting sshd. It is also crucial to review logs for any unusual 'Accepted password for' entries related to passwordless accounts and to monitor for unexpected 'doas' activity or newly added authorized keys.
Alpine recommends treating machines as compromised if unauthorized access cannot be definitively ruled out. The company has released patched packages for affected versions, including 3.21.10, 3.22.8, 3.23.8, and 3.24.4, as well as older branches, indicating that a lower OpenSSH version number does not automatically mean a system remains vulnerable. Proactive security measures and prompt patching are essential to mitigate the risks associated with this authentication bypass vulnerability.