News OpenSSH Flaw lets Attackers log into Password-Disabled Linux Accounts.

[Fixxx]

A newly disclosed flaw involving OpenSSH and musl, dubbed "*sshole," allows attackers to log in to certain Alpine Linux and other musl-based Linux accounts configured to block password authentication simply by entering an oversized password. The flaw only affects OpenSSH servers running on Linux distributions that use the musl C library, including Alpine Linux, OpenWrt, Buildroot, and Yocto, under certain authentication configurations. Security researcher Ozgun Kultekin, who discovered and released details on the vulnerability today, says the flaw has existed since 2016 and stems from how OpenSSH handles password verification errors on systems using the musl C library. Linux accounts can be configured to prevent password logins by replacing their password hash with an asterisk (*) in the /etc/shadow file. Because this is not a valid password hash, no password should allow access to those accounts. However, a patch introduced in OpenSSH in 2016 to fix a username enumeration vulnerability tracked as CVE-2016-6210 changed how OpenSSH handled accounts without usable password hashes. To prevent attackers from identifying valid usernames through different response times, OpenSSH was modified to perform password hashing even when an account had no usable password hash, including accounts configured with * to block password logins. The problem is that the musl C library's crypt() function also returns * when password hashing fails, including when a submitted password exceeds its 256-byte limit. This means an attacker can submit an oversized password and cause OpenSSH to compare the returned * against the account's stored *, resulting in a successful login. To be clear, the flaw does not allow attackers to bypass passwords on accounts with valid password hashes. Kultekin says exploitation requires the following conditions:

• OpenSSH is running on a musl-based Linux system, such as Alpine Linux, OpenWrt, Buildroot, or Yocto.
• PAM authentication is disabled, as it is by default in Alpine Linux's 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 researcher warns that Alpine Linux's official AWS and Azure cloud images have an affected default 'alpine' account with passwordless 'doas' privileges, which could allow attackers to gain root access. Systems using glibc, including Debian, Ubuntu, and Fedora, and those using PAM authentication are not vulnerable to this attack. Kultekin says he discovered the vulnerability using AI agents that ran about 17,600 authentication tests with different OpenSSH configurations, malformed password hashes, and oversized passwords. The vulnerability has been fixed in OpenSSH 10.6p2, and Alpine Linux administrators are advised to update their OpenSSH packages using apk upgrade openssh. Admins who can't immediately install the update can mitigate the issue by turning off SSH password authentication with PasswordAuthentication no in their SSH server configuration and restarting SSH. Kultekin says admins can also check for signs of exploitation by examining SSH authentication logs for password-based logins for accounts that should not allow them. On Alpine Linux, the following command can reveal successful SSH password logins:

grep "Accepted password" /var/log/messages​

If the logs show a successful password login for the alpine account, administrators can check whether that account has password authentication disabled:

grep '^alpine:' /etc/shadow​

If the account's password field contains *, but SSH logs show a successful password login, it could indicate that the vulnerability was exploited.