Musl password flaw hands over root access

A password longer than 256 bytes should be rejected as malformed, not treated as a key to accounts that were never meant to accept passwords at all. According to research published by Wakefield researcher Özgün Kültekin, on certain Linux systems running the musl C library, an attacker could exploit that gap to obtain root access. Kültekin has dubbed the vulnerability *sshole, and OpenSSH shipped a fix in build 10.6p2 released Thursday.

The finding matters beyond the lab because musl is not a fringe choice. It is the standard C library for Alpine Linux, which publishes official cloud images for AWS and Azure, and its small footprint makes it common in embedded Linux deployments. Not every musl system is exposed, but the configuration required is far from exotic.

Conditions that make an attack possible

Kültekin's writeup lays out a narrow but specific set of requirements. The target must run musl libc rather than the more common GNU C library. It must run OpenSSH's secure shell daemon without Pluggable Authentication Modules (PAM), and password authentication must be enabled.

Two account conditions must also hold. At least one account must carry a valid password hash, and the targeted account must have an asterisk in its password field — the marker systems use for accounts that are not supposed to accept password logins. When all of that lines up, an attacker can supply a password between 257 and 1,024 characters to reach accounts that should be closed to password entry, including root, key-only deployment users, and LDAP users.

Direct root login still depends on how OpenSSH itself is configured, so the flaw does not automatically hand over the keys on every affected host. But on systems where the remaining conditions are met, the asterisk marker stops doing the job it was designed to do.

The asterisk dates back to BSD Unix

To understand why a single character in a password field could be bypassed, Kültekin traces the convention to the BSD Unix era, well before OpenSSH existed. In 1980, Sun Microsystems cofounder and BSD Unix heavyweight Bill Joy was involved in development of BSD Unix, whose password file contained a single asterisk in the /etc/passwd entry for the daemon user.

That asterisk was not a password hash. Its purpose was to effectively disable password authentication for the account. Modern systems keep password hashes in /etc/shadow and use them to verify a plaintext password against a stored value, but asterisks remain in use for accounts that are not meant to accept password logins. The convention survived; its guarantees did not.

How musl turned a failure into a character

The crypt() function generates password hashes for comparison against stored values, and it can return NULL when it cannot compute a hash. Applications that fail to check that return value may crash. Musl libc's developers chose a different path: instead of returning NULL for certain failures, they returned a single character, and the character they picked was the asterisk.

Around the same time, musl added SHA-512-based password hashing. Kültekin notes that this scheme gets slower the longer a password is, which creates a denial-of-service risk if someone floods a server with a very long password. Musl's response was to cap passwords at 256 bytes. That cap is the hinge on which the whole issue turns: a password beyond the cap takes a different path through the library's logic, and on affected systems it can land on the asterisk marker rather than a verified hash.

OpenSSH stepped into the picture in 2016, when it introduced a workaround to stop attackers from enumerating valid account names over SSH. Before that change, sshd could reject authentication attempts for nonexistent users faster than attempts for real accounts, because valid accounts required the server to hash the supplied password before rejecting it. The fix had sshd perform dummy password hashing for invalid users, using an appropriate hashing algorithm and salt, to smooth out the timing differences.

Why the flaw stayed hidden for years

The interaction between OpenSSH's dummy hashing and musl's asterisk-on-failure behavior is what produces the vulnerability. On affected musl-based Linux systems, accounts marked with an asterisk instead of a password hash could be opened by supplying a password longer than 256 bytes. The flaw dates to 2016 in OpenSSH's code, though its roots reach back to the BSD Unix convention described above.

What keeps the exposure bounded is the stack of conditions. A system needs musl, an OpenSSH daemon built without PAM, password authentication switched on, an asterisk-marked account, and at least one other account with a valid password hash. Remove any one of those and the attack path closes.

Kültekin's writeup includes a simple CLI command that administrators can use to check whether any no-password accounts on a sensitive machine recently accepted a password. There is no indication that vulnerable systems have been exploited.

The fix and the fallback

OpenSSH moved quickly. Any build of 10.6p2 or newer is protected, so the primary action is to update. For administrators who cannot update their OpenSSH implementation on an affected system right away, Kültekin's guidance is to disable password authentication and restart the SSH daemon.

That fallback has a certain logic to it. The vulnerability depends on password authentication being enabled; turning it off removes the mechanism the attack relies on. Systems already configured for key-only access may need little more than a configuration check and a daemon restart.

Where musl shows up in practice

The obvious question is how many systems actually combine musl with an OpenSSH build that lacks PAM. Alpine Linux is the largest population, and its official cloud images for AWS and Azure mean some Alpine instances in those environments may be vulnerable depending on their configuration. Embedded Linux systems, where musl's low footprint is an advantage, form another group worth auditing.

Kültekin's research describes the target accounts precisely: root, key-only deployment users, and LDAP users. Those are exactly the accounts administrators assume are safe from password guessing because they were never supposed to accept a password in the first place. The asterisk in their password field was the signal of that intent, and on affected systems the signal was not enough.

Checking exposure before patching

Administrators on musl-based distributions should confirm three things: whether the SSH daemon was built without PAM, whether password authentication is enabled, and whether any sensitive accounts carry an asterisk in place of a hash. The CLI check Kültekin provided can help identify whether a no-password account recently accepted a password, which would be the sign of an attempt that succeeded.

Patching to OpenSSH 10.6p2 or newer addresses the underlying behavior. For systems that cannot be updated promptly, disabling password authentication and restarting sshd is the documented workaround. Neither step requires a rebuild of the C library, which keeps the remediation within reach of most operations teams.

What this means for operators

The narrow conditions may invite some administrators to file this under edge cases and move on. That would be a mistake for anyone running Alpine in cloud environments or maintaining embedded Linux fleets, where the combination of musl and password-enabled SSH is plausible rather than theoretical. The fact that the flaw traces back to 2016 and to a convention from 1980 suggests it is the kind of issue that survives audits precisely because each component looks correct in isolation.

For readers running affected systems, the practical takeaway is to verify the SSH build, confirm whether PAM is in use, and check whether asterisk-marked accounts exist on hosts that matter. Where password authentication can be turned off entirely, doing so removes the attack path and aligns with the key-only model many teams already prefer. This appears to be a case where the fix is straightforward but the inventory work — knowing which systems run musl and how their sshd was compiled — is the harder half of the job.