Password authentication bypass in OpenBSD OpenSSH on musl-based Linux

sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM, lacks a workaround for a password authentication bypass (related to misinterpretation of whether a string is intended to be a password hash). For some configurations of accounts, any password between 256 and 1024 characters succeeds. An example of a platform using musl libc without PAM is Alpine Linux.

• OpenSSH on Linux using musl libc, with PAM disabled for password authentication, is affected before 10.6p2.
• The account conditions include one account with a * password field, at least one other account with a $5$ or $6$ password hash, and enabled PasswordAuthentication. Non-Linux systems, Linux systems using glibc, and Linux systems using PAM for password authentication are outside the scope described by OpenSSH.
• Alpine Linux: the advisory confirms that every release checked from 3.16 through 3.24 and edge is affected before the fixed package. Fixed package versions by branch 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, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7, and 3.16 9.0_p1-r6.
• Alpine openssh-server-pam with UsePAM yes, systems with PasswordAuthentication no, locked accounts using !, and systems with no $-style password hash do not meet the affected conditions described by the advisory.

The flaw is in the sshd password authentication path when OpenSSH runs on Linux with musl libc and PAM disabled. Without PAM, sshd calls crypt() to hash the submitted password and compares the result with the stored password field. For an account whose stored field is too short to contain a salt, sshd may borrow the salt from another account. On musl, crypt() returns the string * as an error indicator when the password exceeds its length limit; * is also commonly used for an account with no password in /etc/shadow, so the comparison can succeed. Exploitation also depends on account layout: one account must have a * password field, another account must have a hash beginning with $5$ or $6$, and password authentication must be enabled. The upstream change in the sshd authentication path adds a minimum length check for values treated as password hashes and improves password-value memory handling. OpenSSH describes the root cause as being outside sshd, but provides a workaround in sshd to block this path.

The flaw is reachable over the network when an SSH service accepts connections and password authentication is enabled. An attacker does not need prior privileges or user interaction, but must know the name of a suitable account and the server must meet the musl, PAM, PasswordAuthentication, and password-field conditions. The attacker submits a password in the length range that triggers the error behavior, which can bypass the password check for an account without a password. The recorded attack complexity is high because multiple environment and account conditions must align. The record marks a public exploit as available, and the supplied references include public reproduction code and a lab environment. Evidence currently available does not establish the extent of exploitation in production environments.

• The direct technical outcome is bypass of the password check in password authentication and creation of an SSH session under the identity of an account meeting the conditions.
• Initial privileges depend on the account reached. If it has a shell or access to protected resources, the attacker may read data, alter configuration, run processes, or establish persistence.
• Impact may extend to higher privileges if the reached account can use doas or has another privilege-escalation path. This is configuration-dependent and is not guaranteed on every affected host.
• The flaw does not affect every Linux host or every account. The host must use musl, omit PAM for password authentication, enable password authentication, and have the required password-field layout.
• For internet-facing SSH services, loss of confidence in password authentication can affect confidentiality, integrity, and availability, but the record does not confirm a specific compromise.

If the conditions are present, an external party may obtain SSH access without knowing the target account's password. Consequences can include unauthorized access to data, system modification, command execution as the affected account, and persistence through SSH keys or newly created accounts. On images or hosts where the account can use doas, the initial access may lead to privilege escalation, depending on the local configuration. The root account is reachable through this path only when the effective PermitRootLogin policy permits the relevant login, although another login-capable account may provide a separate route to elevated privileges. Containers that do not run sshd, systems with password authentication disabled, and configurations using PAM for password authentication are outside the described exposure conditions.

1. Upgrade OpenSSH to 10.6p2, or deploy the fixed package for the Alpine branch in use: 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, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7, or 3.16 9.0_p1-r6.
2. Restart the sshd process after updating. Updating the package alone does not replace the running daemon.
3. If updating is not immediately possible, disable password authentication by setting PasswordAuthentication no, validating the configuration, and restarting sshd. Alpine identifies this as a workaround that closes the vulnerable path.
4. Before disabling password authentication, confirm that SSH key login works and keep the current administrative session open until a new login has been tested.
5. After remediation, review exposed SSH hosts, especially Alpine tiny-cloud images and systems with key-only accounts, for suspicious logins, doas changes, new users, new files, and changes to authorized_keys. If an unauthorized login cannot be ruled out, handle the host as potentially compromised.

1. Inventory Linux systems running sshd and identify the OpenSSH version, whether the system uses musl or glibc, whether the build includes PAM, and the effective UsePAM setting.
2. Check the effective PasswordAuthentication value. Systems with this setting at no do not meet the described exploitation condition.
3. Inspect /etc/shadow and the corresponding account sources for accounts with a * password field, and determine whether any local account has a hash beginning with $5$ or $6$. Distinguish !, which indicates a locked account, from *.
4. Compare the installed openssh package with the fixed package for the deployed Alpine branch, and verify that the running sshd process was restarted after the package update.
5. Review /var/log/messages for sshd entries containing Accepted password for an account that normally has no password, such as a key-only account or the alpine account.
6. On systems matching the exposure conditions, review doas use, recently created users, newly created files, and authorized_keys. The absence of these indicators does not prove that the system is safe.