CZ urges operators to patch decade-old OpenSSH flaw

Zhao highlighted the issue in a November 6 post on X, writing: “Alpine Linux OpenSSH security bug that’s been there for 10 years. Apply the fixes if you haven’t.” His warning concerned vulnerable server configurations; neither his post nor the security notices said Binance systems had been compromised through the flaw.

The bug, named “*sshole” by security researcher Özgün Kültekin of Wakefield, affects some systems using musl-based Linux and OpenSSH without Pluggable Authentication Modules (PAM), if password authentication is enabled and specific account conditions are met. An attacker must know the username of an account whose stored password field contains an asterisk and the machine must have another local account with a compatible SHA-256 or SHA-512 password hash. The advisory says one connection can be enough; repeated password guesses are not required.

Kültekin traced the flaw to changes made between 2012 and 2016. He said musl’s password-hashing function returns an asterisk for passwords longer than its 256-byte processing limit. Combined with OpenSSH’s handling of accounts without valid password hashes, that can allow an oversized password to pass authentication. OpenSSH said the root cause was outside sshd and described its fix as a workaround.

Not all Alpine servers are affected. Systems using PAM for password checks, with password authentication disabled, or in containers without a running SSH server are not vulnerable. The issue may also affect some musl-based OpenWrt, Buildroot and Yocto configurations; OpenWrt normally uses Dropbear, which Kültekin said is not affected.

OpenSSH released version 10.6p2 on November 5. Alpine published fixes for current and older releases dating back to 3.16, identifying versions 3.21.10, 3.22.8, 3.23.8 and 3.24.4 as patched. Administrators should update packages and restart the SSH service, because an update alone does not replace a running server process. If they cannot update, the advisory recommends disabling password authentication after confirming SSH key access works, then restarting sshd.

Alpine also warned that tiny-cloud images from versions 3.18.11 through 3.24.3 could expose administrative access under the right conditions. Although the images are not vulnerable on first boot, adding an account with a compatible password hash can create an exploitable setup. The default alpine account can use doas without a password, potentially allowing an attacker who gains access to reach root privileges. Operators were advised to check SSH logs and treat machines as compromised if unauthorized access cannot be ruled out.