OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux
OpenSSH has issued a critical update to version 10.6p2 to address a vulnerability that allows attackers to log into accounts without passwords on some Alpine Linux servers running the standard openssh-server package. To exploit this flaw, attackers need network access to the server, the account name, and a password between 257 and 1,024 bytes long.
The vulnerability arises when the OpenSSH server (sshd) checks passwords without using the Pluggable Authentication Module (PAM) interface, with password logins enabled, and at least one other account on the machine having a password. The openssh-server package in Alpine is built without PAM, and password logins are enabled by default.
This flaw is linked to how sshd interacts with musl, the C library used by Alpine. Systems not based on musl, including those built on glibc or those that check passwords through PAM, are not affected, according to Damien Miller of the OpenSSH project.
Miller advised users of affected systems to “set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.” As of now, no attacks exploiting this vulnerability have been reported.
Conditions for Exposure
Alpine’s security advisory outlines four conditions that must be met for a server to be vulnerable:
- The server runs the openssh-server package built without PAM or runs openssh-server-pam with UsePAM set to no.
- PasswordAuthentication must be set to yes, which is the default for OpenSSH.
- An account must have `*` as its password field, indicating no password is set.
- At least one other local account must have a password hash starting with `$5$` or `$6$`.
Attackers also need the name of an account with no password. If one account has a password, it can expose all accounts without one. The advisory states that the attack can succeed on every attempt with a single connection.
Accounts without passwords on Alpine include:
- Key-only users created with adduser without a password or with usermod -p ‘*’
- Users from a directory service through musl-nscd, as they lack a shadow entry
- The root account, which has been set as root:* in the base image since around Alpine 3.16
- The alpine user in the official cloud images built with tiny-cloud
While root is protected by the default PermitRootLogin prohibit-password setting, it can be accessed directly if PermitRootLogin yes is set. This protection is ineffective if an exposed account can escalate to root privileges, such as through doas.
The tiny-cloud images from versions 3.18.11 to 3.24.3 grant the alpine user passwordless doas access. These images are secure at first boot but become vulnerable once any `$6$` hash exists on the machine, for instance, after an admin sets a console password. An attacker can then log in as alpine and use doas to gain root access.
Containers that do not run sshd, systems with PasswordAuthentication set to no, and cloud images configured through cloud-init are not affected. Accounts locked with `!` in /etc/shadow are also safe, as are machines where no account has a `$`-style password hash.
The vulnerability is not exclusive to Alpine. Özgün Kültekin of Wakefield, who reported the issue, noted that other musl-based systems such as OpenWrt, Buildroot, and Yocto should be checked.
Fixing the Vulnerability
To resolve the issue on Alpine, users must update their packages and restart the sshd service:
- Update the packages: apk upgrade -U -a
- Restart the server: rc-service sshd restart
Point releases 3.21.10, 3.22.8, 3.23.8, and 3.24.4 already include the fixed package. Although branches 3.16 to 3.21 are past their end of support, they also received fixed packages.
If immediate updates are not possible, disabling password logins can prevent the attack. Users should first ensure their SSH key login is functional and maintain their current session until a new login succeeds. Then, they should set PasswordAuthentication to no, verify the configuration with sshd -t, and restart sshd.
The advisory provides commands to add this setting in a drop-in file in /etc/ssh/sshd_config.d. It also suggests changing every PasswordAuthentication line in /etc/ssh/sshd_config from yes to no. After making these changes, sshd -T | grep -i passwordauthentication should return passwordauthentication no.
Users are advised to check /var/log/messages for sshd entries indicating accepted password logins for accounts without passwords. On exposed machines, it is also recommended to review doas usage, recently created users, files, and authorized keys.
The advisory warns, “If you cannot rule out a login, treat the machine as compromised.”
Understanding the Mechanism Behind the Flaw
The vulnerability exists because sshd checks passwords directly without PAM. It hashes the password attempt using crypt(), the C library function that converts a password into its stored form, and compares the result with the stored field.
An account without a password only contains `*` in that field, which is too short to store a salt. Consequently, sshd uses the salt from another account with a valid hash.
For the `$5$` and `$6$` hash types, musl’s crypt() does not accept passwords longer than 256 bytes, returning `*` to indicate an error. This `*` matches the stored `*`, allowing sshd to accept the login. The maximum length for passwords is sshd’s limit of 1,024 bytes.
This behavior stems from a musl change made on August 9, 2012, which caused a failed crypt() call to return “an unmatchable hash rather than NULL”. The 256-byte limit was introduced on August 29, 2012, to protect servers from denial-of-service attacks. The salt borrowing method was introduced in a July 15, 2016, OpenSSH change that addressed CVE-2016-6210, a vulnerability that allowed attackers to discover existing usernames. Kültekin noted that this issue has persisted since then.
The code change in version 10.6p2 prevents sshd from accepting a match when the stored field is shorter than four characters. OpenSSH describes this as a workaround, stating that the root cause lies outside of sshd.
Rapid Response to the Vulnerability
Miller’s team became aware of the vulnerability earlier in the week and expedited the fix. In the release announcement, he mentioned that the team now views long embargoes as dangerous and primarily beneficial to attackers, as they have observed AI agents identifying the same bugs within hours.
No CVE identifier had been assigned to the vulnerability as of November 5.
Source: The Hacker News