Combined OpenSSH and musl-libc flaws let anyone into Alpine Linux and other distros by typing anything over 256 characters as a password

The internet is still reeling from the PHP engine vulnerability and all other security vulnerabilities found over the past few weeks, and we're not done. Today's special is quite spicy: you can get into Alpine, OpenWRT, and other Linux distros without needing a password, thanks to a combined bug with OpenSSH and musl libc. Just randomly type over 256 characters on the password prompt and you'll be let in through the SSHhole.

It works if you set an empty password for system users, which is the default on multiple distros. The bug is present, though not necessarily enabled, across Buildroot, Yocto, and Void Linux. OpenWRT uses Dropbear for authentication by default, but users can install OpenSSH instead.

The largest concern is by far Alpine, though, as it's pretty much the default choice for what could amount to millions of installs across Docker/Kubernetes/Proxmox containers and endless dependencies thereof, servers, cloud VMs, and embedded devices, among many others. Alpine comes with the requisite conditions set and password authentication enabled by default, which is why it needs immediate patching.

While in practice the vast majority of Alpine and similar installs aren't reachable from the internet, any attacker inside a network, including but not limited to corporate setups, home labs, cloud networks, and VPNs, can let themselves in. Likewise, all it takes is one valid user account, not too hard to get in a large enough corporate environment, and then an attacker is inside the network. Scanning and testing the vulnerability is also trivial.

OpenSSH has already published a fix and an advisory post, as did musl author Rich Felker. Both parties seem to believe the other is at fault, but looking from the outside, blame is shared.

If you've ever looked in the /etc/passwd or /etc/shadow files, you may have noticed a single asterisk as a placeholder for the password hash for accounts with no password — meaning "no password should work." The SSHhole website has all the details, but the snafu happens both when musl's crypt() function returns "*" as an error condition instead of a null value as per usual conventions, and then OpenSSH uses it to compare to a password hash, when it shouldn't. An overly long input then triggers the chain of mistakes.

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.