A newly disclosed OpenSSH vulnerability known as “*sshole” could allow attackers to log in to certain accounts on Alpine Linux and other musl-based Linux systems by submitting an oversized password. The flaw affects specific SSH authentication configurations and arises from how OpenSSH and the musl C library handle failed password hashing.
How the OpenSSH vulnerability works
Linux accounts that should not permit password authentication often contain an asterisk (*) in the password-hash field of /etc/shadow. Because an asterisk is not a valid password hash, it should prevent password-based access to the account.
However, a 2016 OpenSSH change addressing a username-enumeration vulnerability, tracked as CVE-2016-6210, changed how the software handles accounts without usable password hashes. To prevent attackers from identifying valid usernames from differences in response times, OpenSSH performs password hashing even when an account does not have a usable hash.
The issue is that the musl C library’s crypt() function also returns an asterisk when password hashing fails, including when a submitted password exceeds the 256-byte limit. OpenSSH can then compare that returned asterisk with the asterisk stored for the account and incorrectly accept the login.
The vulnerability does not allow attackers to bypass authentication for accounts with valid password hashes.
Systems and configurations at risk
Security researcher Ozgun Krutekin said in details released about the vulnerability that the flaw has existed since 2016. Exploitation requires all of the following conditions:
- OpenSSH is running on a musl-based Linux distribution such as Alpine Linux, OpenWrt, Buildroot or Yocto.
- PAM authentication is disabled by default in the Alpine Linux openssh-server package.
- SSH password authentication is enabled.
- At least one account has an asterisk as its password hash.
- Another account has a valid password hash.
The researchers warned that official AWS and Azure cloud images for Alpine Linux include an affected default alpine account with passwordless doas privileges. Under the vulnerable conditions, this could allow an attacker to gain root access.
Linux distributions that use glibc, including Debian, Ubuntu and Fedora, are not vulnerable to this attack. Systems using PAM authentication are also not affected.
Discovery and available fixes
Krutekin said the vulnerability was discovered with the help of an AI agent that ran approximately 17,600 authentication tests across various OpenSSH configurations, incorrect password hashes and oversized passwords.
The issue is fixed in OpenSSH 10.6p2. Alpine Linux administrators are encouraged to update their OpenSSH packages with:
apk upgrade opensshAdministrators who cannot immediately install the update can reduce the risk by disabling SSH password authentication. Add the following setting to the SSH server configuration and restart SSH:
PasswordAuthentication noChecking for possible exploitation
Administrators can look for successful password logins involving accounts that should not permit password-based authentication by reviewing SSH authentication logs:
grep "Accepted password" /var/log/messagesOn Alpine Linux, administrators can inspect the shadow entry for the alpine account with:
grep '^alpine:' /etc/shadowIf the logs show a successful password login for an alpine account whose password field contains an asterisk, that may indicate that the vulnerability was exploited.
Source: www.bleepingcomputer.com