Meet *sshole, the vulnerability that lets hackers SSH into Linux devices

Devices running some configurations of Alpine Linux, and possibly other distributions, are affected by a decade-old vulnerability that allows attackers to log into devices with no password.

The vulnerability exists in the interaction between OpenSSH, the code library implementing SSH connections, and musl, a lightweight alternative to the libc library that, unlike most other Linux distributions, is used in Alpine. Further, OpenSSH using musl (pronounced muscle) must not use PAM (pluggable authentication modules), a framework that handles user authentication and account-access checks. Alpine is a lightweight, widely used Linux distribution. Other platforms may be affected if they use the same configurations.

One connection, works every time, needs no retries

There are two other conditions necessary for successful exploitation. First, a system must have at least one user account that’s accessible using a password that is hashed using the SHA256 or SHA512 functions. Second, the target system account must be configured to be passwordless, by way of specifying a “*” in the password field in /etc/shadow, the Linux file where password hashes are stored. Passwordless accounts are commonly used for accounts that use certificate-based authentication. This setting is common for certain types of accounts.

When all the conditions are met, the consequences are high.

“An attacker who can reach your SSH port can log in without knowing any password,” Alpine maintainers said Thursday. “It takes one connection, works every time, and needs no retries.”

When logging into a passwordless account, the attacker can gain access by inputting more than 256 characters in the password field.

Security firm Checkpoint said that the use of the SHA256 or SHA512 functions “matters because sshd borrows that account’s salt. Without it, the attack fails.”  Company researchers said their testing also showed that the account must be active, not just hold a hash. Checkpoint further reported that root accounts are safe under the default PermitRootLogin prohibit password setting, though reachable accounts with doas or sudo rights can still become root.