A newly disclosed OpenSSH flaw can let attackers access some Linux accounts by submitting an oversized password, but only when several system and account conditions are met. Binance founder Changpeng Zhao urged operators to install the fixes in a November 6 post on X. OpenSSH and Alpine Linux had released updates the day before.
- Who may be affected: Some musl-based systems running OpenSSH with password authentication enabled and no PAM.
- What the flaw requires: An account with an unusable password entry, another local account with a compatible password hash, and an oversized password attempt.
- What to do: Install the appropriate update and restart SSH. Disable password authentication only after confirming another working way to access the system.
A conditional flaw, not a universal SSH bypass
Security researcher Özgün Kültekin of Wakefield named the vulnerability “*sshole. It affects certain OpenSSH configurations that use the musl C library for password checks without PAM, a framework Linux systems can use to manage authentication.
According to the Alpine Linux advisory, an attacker must know the username of an account whose stored password field contains an asterisk. The system must also have another local account with a compatible password hash. Password authentication must be enabled, and the authentication check must not use PAM.
The flaw depends on how musl handles an overlong password. Its password-hashing function, crypt(), has a 256-byte processing limit. If it cannot process the input, it can return an asterisk. In the affected OpenSSH flow, the server can use another account’s password salt when checking an account without a usable password hash. The returned asterisk can then match the target account’s stored asterisk, allowing the login.
The reported attack does not bypass accounts with valid password hashes. And it does not affect every Linux server running OpenSSH. The C library, authentication setup and local account configuration all matter.
Kültekin traced the relevant OpenSSH behavior to a change introduced in July 2016 to reduce username-enumeration signals, or clues a server can reveal about whether a username exists. OpenSSH’s development team said, “We consider the root cause of this bug to be outside sshd.” The patch addresses the interaction, but the underlying issue involves how the system’s password-hashing function handles oversized input.
Where Alpine cloud images need extra attention
The Alpine Linux advisory says certain tiny-cloud images from versions 3.18.11 through 3.24.3 may be affected if the required conditions are met. The images’ default alpine account can use doas, a tool for running commands with elevated privileges, without a password.
That could give an attacker a route from account access to root, the highest level of administrative control on Linux. But authentication and privilege escalation are separate steps. An attacker must first meet the vulnerability’s conditions and access the account before its doas permissions matter. Alpine says the images are not vulnerable on first boot. Adding an account with a compatible password hash can create the conditions for exploitation.
Other systems using musl, including certain OpenWrt, Buildroot and Yocto configurations, may also need review. That does not mean every installation of those projects is vulnerable. OpenWrt normally uses Dropbear rather than OpenSSH for SSH, and Kültekin said Dropbear is not affected by this flaw.
Typical glibc-based configurations, including those commonly used by Debian, Ubuntu and Fedora, are not affected by this particular musl-related issue. Administrators should check the actual library and authentication setup on their systems rather than relying on the distribution name alone.
Updates and practical checks
OpenSSH released version 10.6p2 on November 5 to address the issue. Alpine listed fixed releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and said patched packages cover current releases and older versions back to 3.16. Distributions may backport fixes, so operators should follow their distribution’s advisory and confirm that the installed package is patched instead of relying only on the upstream version number.
Alpine administrators can update the OpenSSH package with:
apk upgrade openssh
Restart the SSH service after updating to make sure the patched server is running. If you cannot install a fix right away, Alpine advises setting PasswordAuthentication no and restarting sshd. First confirm that key-based access works. Otherwise, the mitigation could lock administrators out of the machine.
Check SSH authentication logs for unexpected successful password logins, especially for accounts that should not accept password authentication. Log locations vary, so use the tools appropriate for your system. A suspicious login warrants investigation, but does not by itself prove that someone used this specific flaw.
CZ wrote on X: “Alpine Linux OpenSSH security bug that’s been there for 10 years. Apply the fixes if you haven’t, ” The warning is a reason for operators to check their systems, not evidence that Binance was affected. Available security notices and reporting do not establish that Binance systems were compromised through this vulnerability, and they do not publicly confirm exploitation in the wild.
Key questions and answers
-
Does this affect every Linux server running OpenSSH?
No. The reported bypass requires a specific combination of musl, authentication settings and local account conditions. It is not a general-purpose SSH backdoor.
-
Can the flaw bypass a valid account password?
The reported attack does not bypass accounts with valid password hashes. It targets an account with an unusable password entry, such as an asterisk, when the other required conditions are present.
-
Can the flaw lead to root access?
Potentially, on the Alpine tiny-cloud configurations identified: if an attacker gains access to the alpine account, its passwordless doas privileges could provide a path to root. Gaining account access and escalating privileges are separate steps.
-
What should administrators do?
Install the fix specified by their distribution and restart SSH. If patching has to wait, disable password authentication only after confirming another working access method, then check authentication logs for suspicious activity.
-
Does CZ’s warning mean Binance was compromised?
No. The warning and security notices do not establish that Binance systems were affected. Available reporting also does not publicly confirm exploitation of the flaw.
