Any long password will do: SSH flaw lets hackers into Alpine systems, routers and more

A massive decade-old flaw affects Alpine and other distributions that run OpenSSH on the musl library. Containers, routers, IoT devices, and other applications are critically vulnerable. Emergency updates are available.

Any long password, between 257 and 1024 characters, unlocks thousands of Linux systems via SSH (Secure Shell), the industry standard for remote system administration. Attackers only need to reach the vulnerable systems over the SSH port.

If you run OpenSSH on Alpine Linux, OpenWrt, or any other system depending on the musl library, update immediately, warns Özgün Kültekin (@kultekin), a security researcher who discovered the flaw and dubbed it “*sshole.”

Alpine’s Docker image alone has over 30 million weekly downloads.

“An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries,” the Alpine Linux security advisory confirms.

The exploit targets only user accounts without a password set. However, the root (superuser) account is often configured this way, as are many other system or service users. Alpine Docker images come with no root password by default.

“That means root, key-only users, LDAP users, the alpine user on Alpine’s cloud images. Since 2016,” the researcher said.

Alpine Linux is an extremely lightweight and efficient Linux distribution, widely used in containers, microservices, routers, embedded devices, and other applications.

The vulnerability is so embarrassing that it is quickly turning into a meme among cybersecurity professionals.

Who’s affected?

The flaw affects tiny Linux systems that rely on the musl translation layer – it helps software communicate with the OS.

Musl is used in Alpine Linux, Void Linux, OpenWrt, which powers many home routers and embedded networking devices, and many other specialized projects. The vast majority of large Linux distributions rely on heavier implementations like glibc.

Systems are vulnerable when they run an affected version of OpenSSH without PAM-based authentication checks – a configuration that is often the default.

Password authentication must also be enabled, with at least one user account having a password set. An attacker can then access other accounts whose password field is set to an asterisk (*).

“A fresh box with no passwords set isn't affected,” the researcher said.

Alpine locks the root account by default, and OpenSSH blocks password logins using the PermitRootLogin prohibit-password setting. However, attackers can still log in as other users and escalate their privileges using tools such as doas.

The researcher also lists Buildroot Yocto-based systems and “a lot of the Docker images you've pulled” as potentially exposed.

Why does any long password work?

Unix-like systems use the asterisk (*) in configuration files to indicate that an account has no password. Real user passwords are stored and verified as hashes, and an asterisk can never match a hash and unlock an account.

In 2012, the musl library added SHA-512 hashing, which becomes slower as passwords get longer.

“Someone could send one giant password and keep your server busy for a long time. So musl just caps it at 256 bytes and refuses anything longer,” the security researcher explained on a dedicated sshhole.com website.

When it musl rejects a long password, it returns an asterisk on error, signaling failure.

Meanwhile, OpenSSH, a universally used secure networking tool, includes a timing defense. If someone tries to log in to an account that doesn’t exist or has no usable password, the SSH daemon still runs a throwaway hashing and comparison, so an attacker can’t tell real accounts from fake ones by measuring response time.

Here’s how these pieces fall together: an attacker tries to SSH into an *-locked account and types 257+ characters for a password. Musl fails to hash it and returns an asterisk. OpenSSH compares it to the account’s stored value, also an asterisk – they match. The attacker gets in.

“musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds,” reads the Alpine’s advisory.

Kültekin also released a comic explaining the exploit.

Updates available

Alpine’s latest releases now include a fixed OpenSSH version.

“If you run sshd on Alpine Linux, update openssh now and restart sshd. Upgrading the package alone does not replace the running daemon,” the advisory urges.

For those who can’t update immediately, Alpine recommends disabling password authentication in the SSH configuration and has published instructions.

The advisory also recommends checking whether the system has already been attacked by reviewing the SSH log for any successful logins to accounts that shouldn’t have a password, and looking for anything new, such as recent admin (doas) activity, new users or files, unfamiliar SSH keys, and other signs.

“If you cannot rule out a login, treat the machine as compromised.”

The implications of a compromise can be devastating: an attacker with root access can steal data and credentials, install malware or backdoors, wipe the server, and potentially take over the entire host or use the system as a foothold to attack other systems on the network.