Sshole

A flaw in OpenSSH on musl-based Linux systems can let password authentication succeed for accounts that are meant to have no password, including key-only users and some default cloud-image accounts. The vulnerable setup requires OpenSSH to run without PAM, password logins to remain enabled, an account whose shadow password field is “*”, and another account with a real password. In that combination, passwords from 257 to 1,024 characters can authenticate as the locked account; on Alpine cloud images, that may grant root access through the default user’s passwordless privilege escalation.

The problem comes from interacting behaviors. Musl’s crypt function returns “*” when a password exceeds its 256-byte processing limit, rather than returning an error. OpenSSH’s defense against timing attacks hashes passwords for invalid users using another account’s salt. When the oversized password causes crypt to return “*”, that result matches the locked account’s “*” field, so OpenSSH accepts it. Testing across 17,600 unusual logins found the issue only with musl and no PAM; glibc, PAM-based configurations, and several other SSH setups are not affected. OpenSSH 10.6p2 fixes the flaw. Until updated, administrators should disable password authentication and check logs for successful root logins.