OpenSSH and musl libc combined flaw enables passwordless root access on Alpine Linux with 256+ character input
An interaction between musl's crypt() returning "*" on error and OpenSSH's improper hash comparison allows authentication bypass on Alpine Linux and other musl-based distributions when any password over 256 characters is entered.
Summary
A critical authentication bypass vulnerability, dubbed "SSHhole," affects Alpine Linux and other distributions using musl libc combined with OpenSSH, allowing attackers to gain access by typing any password longer than 256 characters. The flaw stems from musl's crypt() function returning a single asterisk ("*") as an error condition for oversized input rather than null, which OpenSSH then incorrectly compares against password hashes. Alpine Linux is particularly exposed because it ships with the vulnerable conditions pre-configured: musl as its C library, OpenSSH with password authentication enabled by default, and SHA-512/256 password hashes without PAM. The vulnerability also exists in Buildroot, Yocto, and Void Linux configurations, though OpenWRT avoids it by defaulting to Dropbear rather than OpenSSH.
Both OpenSSH and musl author Rich Felker have issued emergency patches and advisories, with each project attributing primary responsibility to the other. The attack requires only network access to an affected system and knowledge of any valid username; scanning and exploitation are trivial. Immediate mitigation involves setting PasswordAuthentication to no in sshd_config and restarting the SSH service, though patching both components is essential for permanent resolution.
How the crypt() return value mishandling enables authentication bypass
- musl crypt() behavior: musl's crypt() function returns the string "*" when presented with input exceeding 256 characters, rather than returning NULL to signal an error condition as conventional implementations do.
- OpenSSH comparison logic: OpenSSH accepts the "*" return value and performs a string comparison against the stored password hash in /etc/shadow, instead of treating non-NULL error returns as authentication failures.
- Default Alpine configuration: Alpine Linux enables password authentication in OpenSSH by default, uses musl libc rather than glibc, does not use PAM for authentication, and employs SHA-512/256 password hashes, satisfying all conditions for the vulnerability chain.
- Affected ecosystem scope: The vulnerable configuration is present though not necessarily enabled in Buildroot, Yocto, and Void Linux; OpenWRT avoids the issue by defaulting to Dropbear but becomes vulnerable if OpenSSH is installed.
- Trigger mechanism: Entering any password input longer than 256 characters causes musl's crypt() to error-return "*", which OpenSSH then matches against the hash field, resulting in successful authentication regardless of the actual password.
Why it matters
This vulnerability carries severe implications for container and cloud infrastructure, as Alpine Linux underpins millions of Docker, Kubernetes, and Proxmox deployments where SSH access may be exposed internally or through misconfiguration. The ease of exploitation—requiring only a known username and arbitrarily long keyboard input—makes this particularly dangerous for corporate networks, home labs, and cloud VPCs where attackers with any network foothold can pivot to full system access. System administrators must audit all musl-based systems immediately, as the default-enabled password authentication on Alpine creates widespread exposure even on systems not directly internet-facing.
What to do
- Patch OpenSSH and musl-libc immediately as per their respective project advisories.
- Set 'PasswordAuthentication' to 'no' in your sshd_config file and restart the SSH service to mitigate the issue.
Original reference: www.tomshardware.com →