NewsCSO Online

    OpenSSH flaw lets attackers access password-disabled accounts on some Linux systems

    Share
    A critical vulnerability that affects OpenSSH servers on Linux systems built with the musl C library instead of glibc allows remote attackers to easily bypass authentication and log into accounts that should have password authentication disabled. The flaw impacts the lightweight Alpine Linux, which is widely used for cloud Docker container images, as well as Linux distributions for embedded systems. The security bug, dubbed *SSHole and tracked as CVE-2026-123158 , was discovered by Ozgun Kultekin, a researcher with security testing firm Wakefield, and has existed for the past 10 years. The OpenSSH maintainers moved quickly to add mitigation for the flaw in the OpenSSH 10.6p2 emergency update released Thursday, even though they claim the bug is not actually in their code . “It’s not every day that the ‘exploit’ for a vulnerability in a technology as prevalent as OpenSSH is just ‘send a long password’ or ‘send a lot of A characters,’ but here we are,” said Jake Knott, head of threat intelligence at preemptive exposure management firm watchTowr. “On affected systems, the exploit is strikingly simple: send a password between 257 and 1,024 characters long.” Luckily, there are some prerequisites for this exploit to work: The Linux distribution needs to use musl, which means that many popular server distros such as Debian, Ubuntu, and Fedora are not impacted The system needs to use OpenSSH and not alternative SSH server implementations such as Dropbear, which many embedded distros use OpenSSH needs to be configured without support for Pluggable Authentication Modules (PAM), the most common Linux login framework OpenSSH needs to allow password-based authentication The attacker needs to know the name of an account for which password login has been disabled at the system level Those conditions are met in default configuration for Alpine Linux and its built-in “alpine” username, which allows executing commands as root. The Alpine project released emergency updates for the openssh package and advises users who can’t update to disable password-based authentication in the OpenSSH configuration and set up key-based authentication. Why the trivial attack works The flaw is the product of three changes made years apart, each solving a different problem. In 2012, musl’s developers capped password length at 256 bytes to stop attackers from tying up server resources by sending long passwords that need to be hashed as part of the login verification process. At the same time they also made the library’s password hashing function return an asterisk (*) whenever it fails. The asterisk is the same character Unix has used since the 1980s to mark accounts for which no password should ever match — accounts with password disabled at the system level. In 2016, OpenSSH changed how it checks passwords for accounts whose own password field offers no salt to hash against, borrowing another account’s salt so that attackers could not guess existing usernames with brute-force login retries and timing the server’s responses. Then in 2022, Alpine switched root’s password field to an asterisk so that SSH key logins would keep working for it. When an attacker sends an over-long password for a password-disabled account on such a system, the hash attempt fails and returns an asterisk, which sshd compares with the asterisk stored in the account’s password field. The two match, and the login succeeds. Alpine Linux cloud images will be the main target Alpine’s standard OpenSSH package is built without PAM, and password logins are enabled by default, so Alpine servers meet the conditions out of the box. On the official cloud images published between versions 3.18.11 and 3.24.3, the default user account, named alpine, is one of the password-disabled accounts, and the images grant it passwordless “doas” privileges. As a result, an attacker who logs in as that user can then switch to root, so the images are exposed as soon as an administrator sets a password for any other account on the system, because a legitimate account with a real password needs to exist for this attack to work. Unlike the critical regreSSHion flaw from 2024 , this one is confined to the musl world, but it requires no exploit engineering of any kind. “Internet-exposed SSH servers are already being hammered by password guesses and brute-force attempts around the clock ,” Knott said. “Exploiting this vulnerability simply means those same attackers add a very long password attempt to that brute-force list. We’d be extremely surprised if we didn’t see SSH brute-forcers attempting this by the weekend.” Organizations should also check whether the flaw was already used against their servers. An “Accepted password” entry in /var/log/messages for an account that has no password, such as root, a key-only user, or the default alpine user, is a strong sign of compromise. Alpine recommends reviewing doas usage, recently created users and files on exposed machines, and its advisory says any server where a login cannot be ruled out should be treated as compromised. Kultekin also published a check script on GitHub that identifies exposed servers and lists the accounts at risk.

    Linked advisories

    Affected vendors and products

    More on OpenSSH

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4245407/openssh-flaw-lets-attackers-access-password-disabled-accounts-on-some-linux-systems.html

    ID