Get root on a musl Linux system by slamming it with an overly long password

Decade-old vulnerability in OpenSSH is now fixed, so get a-patchin' 

On certain Linux systems, an attacker could gain root access by entering a password longer than 256 bytes. The vulnerability, dubbed *sshole by Wakefield researcher Özgün Kültekin, who discovered it, can only be exploited in very specific conditions.

The flaw affects certain Linux systems using musl libc instead of the traditional GNU C library, and even then only those running OpenSSH's secure shell daemon without Pluggable Authentication Modules (PAM) and with password authentication enabled.

If those conditions are met, and at least one other account has a valid password hash, accounts that shouldn't accept passwords, such as root, key-only deployment users, and LDAP users, may be accessed by supplying a password between 257 and 1,024 characters. The targeted accounts must have an asterisk (*) in their password field, and direct root login remains subject to OpenSSH's configuration.

REG AD

That might seem niche, but sorry: It’s not. 

REG AD

Musl libc is common in embedded Linux systems due to its low footprint. More critically than that, it's also the standard C library for Alpine Linux, which provides official cloud images for both AWS and Azure. Some Alpine systems running in those environments may therefore be vulnerable, depending on their configuration. 

Dawn of the *sshole

The vulnerability in OpenSSH 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, actually.

In 1980, Sun Microsystems cofounder and BSD Unix heavyweight Bill Joy was involved in the development of BSD Unix, whose password file contained a single asterisk in the /etc/passwd entry for the daemon user. The asterisk wasn't a password hash and effectively disabled password authentication for that account.

Nowadays, password hashes typically live in /etc/shadow and contain hashed information that the system uses to verify a plaintext password entered by a user. Asterisks are still present for accounts that aren't supposed to accept password logins, but as Kültekin explains in his writeup, that isn't exactly a foolproof way to keep people out.

The crypt() function, which generates password hashes for comparison with stored values, can return NULL if it can't compute a hash. Applications that fail to check that result may crash. Musl libc's developers instead chose to return a single character for certain failures, and they picked the asterisk.

Musl also added SHA-512-based password hashing around the same time, which Kültekin notes gets slower the longer a password is, potentially leading to denial of service if someone floods a server with a super-long password. Musl capped passwords at 256 bytes, and you can likely see where this is going. 

In 2016, OpenSSH introduced a workaround to prevent attackers from enumerating valid account names through SSH. Before the change, sshd could reject authentication attempts for nonexistent users more quickly than those for valid accounts. Attempts against valid accounts took longer because the server had to hash the supplied password before rejecting it. The solution was to have sshd perform dummy password hashing for invalid users, using an appropriate hashing algorithm and salt to reduce differences in response times.

REG AD

On affected musl-based Linux systems, accounts marked with an asterisk instead of a password hash could be busted open by supplying 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.

Luckily, OpenSSH acted fast to fix this issue, and any OpenSSH build 10.6p2 (released Thursday) or newer is protected. Alternatively, if you can’t update your OpenSSH implementation on an affected system, just disable password authentication and restart the SSH daemon and you should be all set. 

There’s no indication that vulnerable systems have been exploited, but if you want to check, Kültekin has included a simple CLI command in his writeup that can be used to check if any no-password accounts on a sensitive machine recently took a password.  ®