OpenSSH and musl behaviours combined to let long passwords open locked accounts

Three behaviours, one wrong result

Some security flaws have no single culprit. Independent researcher Ozgun Kultekin describes a login bypass that comes from how a C library reports failure, a password length limit, and an OpenSSH change made in 2016. Together they let a long password open a locked account.

The OpenSSH change targeted invalid usernames. Kultekin says the fix, it turns out, also covered real accounts locked with an asterisk. BleepingComputer reports that OpenSSH 10.6p2 fixes the flaw.

The lesson for a technology leader is that software can look sound part by part and still fail where the parts meet. The sources describe no test that covered where these components meet.

How a locked account is supposed to work

Linux stores each account's password check in a file called /etc/shadow. A real entry holds a salted hash, which is a scrambled fingerprint of the password. To log in, the server hashes what you type and compares it with the stored value.

Administrators lock an account by putting a single asterisk where the hash would go. Kultekin notes this convention dates to 1980. An asterisk is not a hash, so no typed password should match it. The researcher lists key-only users, LDAP users and root on Alpine as examples of accounts with only an asterisk.

The mechanism: a failure signal that looks like a lock

The flaw combines three behaviours. The first is in musl, the small C library that Alpine Linux uses. Its password-hashing function, crypt(), can fail. Many programs do not check for failure, so musl returns a single asterisk instead. Those programs then see a wrong password rather than crashing.

The second is also in musl. It caps password length at 256 bytes, so one giant password cannot keep a server busy. A longer password makes crypt() fail, so it returns an asterisk.

The third is OpenSSH's 2016 fix for CVE-2016-6210. That bug let attackers learn which usernames exist by timing responses. The fix makes the server hash the password even when there is no real hash to check, so every answer takes similar time. Kultekin says this also covered real users with an asterisk. BleepingComputer reports the same.

Now join them. An attacker sends a password longer than 256 bytes. Musl's crypt() fails and returns an asterisk. OpenSSH compares that asterisk with the locked account's asterisk. They match, and the login succeeds.

Who is exposed, and who is not

The conditions are narrow. Kultekin lists them. The server runs musl, such as Alpine Linux, OpenWrt, Buildroot or Yocto. It does not use PAM, a common authentication layer. Password logins are on, which is the default. One account has only an asterisk as its password, and another account has a real password. With no real hash to check, OpenSSH borrows another account's salt, so a second account with a real password is needed. Then the locked account accepts any password between 257 and 1,024 characters.

BleepingComputer reports the flaw does not bypass accounts that have valid password hashes. Kultekin says systems using glibc, such as Debian, Ubuntu and Fedora, are not affected. Neither are systems that go through PAM, Dropbear or OpenBSD.

The cloud images carry the highest stakes. Kultekin says the default alpine user on Alpine's official AWS and Azure images has passwordless doas, which grants root. On those images, an exposed account means root access.

Why it stayed hidden

Kultekin points to gaps in testing. OpenSSH is tested on OpenBSD and glibc. Musl does not test sshd. Most distributions use PAM, which does not call crypt() for an asterisk account. His explanation is that the combination fell between test suites.

He also describes near misses. A Debian thread asked glibc to copy musl's "*" behaviour. A busybox thread about a 257-character password hit the same asterisk and the same limit, but never mentions sshd. A security review fixed pick_salt() in OpenSSH, four lines above the bug, four days before he found it. Kultekin adds that, as far as anyone knows, nobody noticed the flaw.

He says he built sshd in many configurations, including glibc, musl, with and without PAM. He says he used agent swarms to run about 17,600 logins across configurations. Only one setup disagreed with the rest: musl without PAM accepted logins the others refused.

What to ask your team

Start with an inventory. Which hosts, containers and devices run musl-based systems, and do any also run OpenSSH without PAM? Include network gear and embedded devices built on OpenWrt, Buildroot or Yocto. Which of them have an account with only an asterisk next to an account with a real password?

Then act on the fix. It is in OpenSSH 10.6p2. On Alpine, BleepingComputer reports the command is apk upgrade openssh. If you cannot update yet, set PasswordAuthentication no in the SSH server configuration and restart SSH.

Next, check for past use. Kultekin suggests reviewing SSH logs for successful password logins on accounts that should not allow them. A password login on an account whose shadow entry is an asterisk could indicate exploitation.

Finally, look at your own code. Do any in-house wrappers or scripts call crypt() and compare the result with the stored field without checking for an error? Does any of them treat a failure value as an ordinary string? Ask suppliers the same question, and whether they test their software on the library and login settings they ship.

A lock that opens when the check cannot finish is a design question, not only a patching one. Ask what each system does when a check fails, and whether that failure can look like an answer.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Ozgun Kultekin (independent security researcher), who published the disclosure at sshhole.com.