OpenSSH and musl bugs let a 256+ character password bypass login

Two separate bugs in OpenSSH and the musl libc library combine to allow password authentication to be bypassed. All an attacker has to do is type a random string longer than 256 characters at the SSH password prompt. Because many distributions define empty passwords for system users by default, the attack works directly in that scenario. The flaw affects Alpine Linux and some other distributions.

The disclosure follows a string of recent vulnerabilities, including ones in the PHP engine. The scope of this one stands out mainly because of how widely Alpine is used in container and cloud environments.

Which systems are affected?

Exploitation requires several conditions to line up: OpenSSH must be in use, musl libc must be the C library, password authentication must not have been explicitly disabled, PAM must not be active, and there must be a single arbitrary user account with a password set using a SHA-512/256 hash. Since empty passwords for system users are the default on many distributions, the attack works in this scenario.

The bug is also present in Buildroot, Yocto and Void Linux, though it may not always be active there. OpenWRT uses Dropbear for authentication by default, although users can choose to install OpenSSH. The biggest concern is Alpine, where the required conditions are met out of the box and password authentication ships enabled. Given how common Alpine is in Docker, Kubernetes and Proxmox containers, on servers, in cloud virtual machines and in embedded devices, the number of affected installations could reach into the millions.

How the bug works

The technical root of the problem has two parts. For accounts without a password in /etc/passwd or /etc/shadow, a single asterisk is used in place of a password hash, which is meant to signify that no password will ever work. musl's crypt() function, however, returns "*" on an error rather than null, as would be the usual approach. OpenSSH then compares that value against a password hash, which it should not do. An excessively long input triggers this chain of errors.

The details are published on a website called SSHhole. OpenSSH has released a fix and a security advisory, and musl's maintainer Rich Felker has done the same. The two sides appear to place responsibility on each other, but from the outside it looks like the blame is shared.

Risks and mitigations

Most affected systems are thought not to be directly reachable from the internet. Even so, any attacker inside the network, including corporate networks, home labs, cloud networks and VPNs, could get in. Only one valid user account is needed, which is not hard to obtain in a large corporate environment. The flaw is also easy to scan for and test.

Systems should be patched immediately in line with each project's advisory. The easiest interim workaround is to explicitly set "PasswordAuthentication" to "no" in the OpenSSH configuration file and restart the service.