Security researcher Ozgun Kultekin has disclosed a vulnerability affecting OpenSSH deployments on musl-based Linux distributions. The flaw, which Kultekin named "*sshole," permits attackers to authenticate to accounts that have been explicitly configured to reject password-based logins. The attack works by submitting a password that exceeds the normal size limit, triggering a specific behavior in the musl C library's cryptographic functions.
The vulnerability impacts only OpenSSH servers deployed on Linux systems using the musl C library, such as Alpine Linux, OpenWrt, Buildroot, and Yocto. Kultekin notes that the issue has been present since 2016 and originates from how OpenSSH processes password verification failures on musl-based platforms.
How the Vulnerability Works
System administrators typically disable password authentication on specific accounts by replacing the password hash in /etc/shadow with an asterisk (*). Since this is not a valid cryptographic hash, no legitimate password should grant access to such accounts.
In 2016, OpenSSH introduced a patch to address CVE-2016-6210, a username enumeration vulnerability. The patch modified OpenSSH to perform password hashing operations even when an account lacked a usable password hash. This change was designed to prevent attackers from distinguishing valid usernames based on response time differences.
The musl C library's crypt() function returns an asterisk when password hashing fails, including when the submitted password exceeds 256 bytes. An attacker can exploit this behavior by providing an oversized password, causing OpenSSH to compare the asterisk returned by the hashing function against the asterisk stored in the account's password field, resulting in a successful authentication.
Importantly, the vulnerability does not compromise accounts that have valid password hashes configured. It only affects accounts explicitly disabled with an asterisk.
Exploitation Requirements
Kultekin identified specific conditions that must be present for successful exploitation:
- OpenSSH operates on a musl-based Linux distribution such as Alpine Linux, OpenWrt, Buildroot, or Yocto
- PAM authentication is disabled, which is the default configuration in Alpine Linux's openssh-server package
- SSH password authentication is enabled
- At least one account has an asterisk (*) configured as its password hash
- Another account maintains a valid password hash
Kultekin warns that Alpine Linux's default cloud images on AWS and Azure contain an affected 'alpine' account with passwordless doas privileges, potentially enabling attackers to escalate to root access.
Systems running glibc-based distributions such as Debian, Ubuntu, and Fedora, as well as those with PAM authentication enabled, remain unaffected by this attack.
Discovery and Remediation
Kultekin discovered the vulnerability through automated testing using AI agents that executed approximately 17,600 authentication tests across various OpenSSH configurations, malformed password hashes, and oversized passwords.
OpenSSH 10.6p2 contains a fix for the vulnerability. Alpine Linux administrators should update their OpenSSH packages by running apk upgrade openssh.
For systems unable to deploy the update immediately, administrators can disable SSH password authentication by setting PasswordAuthentication no in the SSH server configuration file and restarting the SSH service.
Detection and Investigation
Kultekin recommends examining SSH authentication logs for signs of exploitation. Administrators should look for password-based logins to accounts that should not permit such access.
On Alpine Linux systems, the following command reveals successful SSH password authentications:
grep "Accepted password" /var/log/messages
To verify whether an account has password authentication disabled, administrators can check the account's entry in /etc/shadow:
grep '^alpine:' /etc/shadow
If the password field contains an asterisk but SSH logs record successful password logins for that account, this may indicate exploitation of the vulnerability.