Combined flaws let anyone in Alpine Linux and other distros type anything over 256 characters as a password – emergency fixes for OpenSSH and musl-libc released for millions of systems, patching immediately
Follow us
Add us as a preferred source on Google
Subscribe to our newsletter
The internet is still reeling from the PHP engine vulnerability and all the other security vulnerabilities found in the past few weeks, and we’re not done yet. Today’s special is pretty cool: 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 at the password prompt and you’ll be let in through the SSHhole.
It works if you set a blank password for system users, which is the default on some distros. The bug is present, but not necessarily enabled, across Buildroot, Yocto, and Void Linux. OpenWRT uses Dropbear for authentication by default, but users can install OpenSSH instead.
The biggest concern is by far Alpine, however, because it is pretty much the default choice for what millions of installations via Docker / Kubernetes / Proxmox containers and endless dependencies thereof, servers, cloud VMs, and embedded devices, among many others. Alpine comes with the required conditions set and password authentication enabled by default, so it needs immediate patching.
Latest Videos FromTom’s hardware
Broadly speaking, the vulnerability combination is: OpenSSH, musl, password authentication not explicitly disabled, not with PAM, and the arbitrary user with a password set, with a SHA-512/256 hash.
Patch your systems immediately, as per the project’s advisory note. Meanwhile, the easiest mitigation is to explicitly set “PasswordAuthentication” to “no” in your OpenSSH configuration file and restart the service.
While in practice the vast majority of Alpine and similar installations are not reachable from the Internet, any attacker on a network, including but not limited to corporate setups, home labs, cloud networks and VPNs, can let themselves in. Scanning and testing the vulnerability is also trivial.
OpenSSH has already published a fix and an advisory post, as has Musl author Rich Felker. Both parties seem to believe that the other is to blame, but from the outside looking in, the 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 without a password – meaning “no password should work.” The SSHhole website has all the details, but the snafu occurs both when Musl’s krypta() function returns “*” as an error condition instead of a null value as usual conventions, and then OpenSSH uses it to compare a password hash when it shouldn’t. A too long input then triggers the chain of errors.
Get Tom’s Hardware’s best news and in-depth reviews, straight to your inbox.
follow Tom’s Hardware on Google Newsor add us as a preferred sourceto get our latest news, analysis, & reviews in your feeds.
