security
A decade-old vulnerability in OpenSSH is now fixed, so install a patch
On some Linux systems, an attacker could gain root access by entering a password longer than 256 bytes. The vulnerability, nicknamed *sshole by Wakefield researcher Özgün Kültekin, who discovered it, can only be exploited under very specific conditions.
The flaw affects some Linux systems using musl libc instead of the traditional GNU C library, and even then only those running the OpenSSH secure shell daemon without pluggable authentication modules (PAM) and with password authentication enabled.
If these conditions are met and at least one other account has a valid password hash, accounts that should not accept passwords, such as root users, key-only deployment users, and LDAP users, can be accessed by providing a password between 257 and 1024 characters. Targeted accounts must have an asterisk
in their password field, and direct root login remains subject to OpenSSH configuration.
This might seem niche, but sorry: it’s not.
The Musl libc is common in embedded Linux systems due to its small footprint. More importantly, it is also the standard C library for Alpine Linux, which provides official cloud images for AWS and Azure. Some Alpine systems operating in these environments may therefore be vulnerable, depending on their configuration.
The dawn of the *asshole
The OpenSSH vulnerability on Musl-based Linux systems dates back to 2016, but Kültekin explains that its roots go back much further – to the BSD Unix era, in fact.
In 1980, Sun Microsystems co-founder and BSD Unix heavyweight Bill Joy helped develop BSD Unix, whose password file contained a single asterisk in the /etc/passwd entry for the daemon user. The asterisk was not a password hash and effectively disabled password authentication for this account.
Nowadays, password hashes are typically found in /etc/shadow and contain hashed information that the system uses to verify a plaintext password entered by a user. The asterisks are still there for accounts that aren’t supposed to accept password logins, but as Kültekin explains in his article, that’s not exactly a foolproof way to keep people out.
The crypt() function, which generates password hashes for comparison with stored values, may return NULL if it cannot calculate a hash. Applications that fail to verify this result may crash. The Musl libc developers instead chose to return a single character for certain failures, and they chose the asterisk.
Musl also added SHA-512-based password hashing around the same time, which Kültekin said gets slower and slower the longer a password is, potentially leading to a denial of service if someone floods a server with a very long password. Musl has limited passwords to 256 bytes, and you can probably see where this is going.
In 2016, OpenSSH introduced a workaround to prevent attackers from enumerating valid account names over SSH. Before the change, sshd could reject authentication attempts from non-existent users faster than those from valid accounts. Attempts against valid accounts took longer because the server had to hash the provided password before rejecting it. The solution was to have sshd do a dummy password hash for invalid users, using an appropriate hashing algorithm and salt to reduce response time differences.
On affected Musl-based Linux systems, accounts marked with an asterisk instead of a password hash could be opened by providing a password longer than 256 bytes – a flaw dating back to 2016. Any Musl-based Linux system running a vulnerable OpenSSH configuration without PAM, with password authentication enabled, at least one account marked with an asterisk and another account with a valid password hash could be vulnerable to a *sshole attack.
Fortunately, OpenSSH acted quickly to resolve this issue, and any OpenSSH version 10.6p2 (released Thursday) or newer is protected. Alternatively, if you cannot update your OpenSSH implementation on an affected system, simply disable password authentication and restart the SSH daemon and you should be all set.
There is no indication that vulnerable systems have been exploited, but if you want to check, Kültekin included a simple CLI command in his article that can be used to check if passwordless accounts on a sensitive machine have recently been password-taken. ®
Gn tech
