OpenSSH 10.6p2 patches *sshole root exploit in musl libc systems
A long-standing interaction between musl libc's crypt() implementation and OpenSSH's dummy hashing workaround allows passwords over 256 bytes to authenticate accounts marked with asterisks, including root on Alpine Linux and embedded systems.
Summary
Security researcher Özgün Kültekin disclosed a vulnerability in OpenSSH on musl-based Linux systems where supplying a password between 257 and 1,024 characters could grant access to accounts whose password field contains an asterisk, including root, key-only users, and LDAP accounts. The flaw, nicknamed *sshole, requires specific conditions: musl libc instead of glibc, OpenSSH without PAM, password authentication enabled, at least one account with a valid password hash, and the target account marked with an asterisk in its password field.
The vulnerability traces to a 2016 OpenSSH change intended to prevent username enumeration through timing attacks, which introduced dummy password hashing for invalid users. Musl libc's crypt() returns a single asterisk for certain failures rather than NULL, and its 256-byte password cap creates a collision when OpenSSH feeds overlong passwords into its dummy hash routine. Alpine Linux, which uses musl and provides official AWS and Azure cloud images, is particularly affected. OpenSSH 10.6p2, released Thursday, contains the fix; disabling password authentication also mitigates the issue.
How the musl crypt() and OpenSSH interaction fails
- Musl libc crypt() behavior: Unlike glibc, which returns NULL on crypt() failure, musl returns a single asterisk character for certain error conditions, creating a collision with the traditional Unix convention of using asterisks to disable password login for accounts.
- OpenSSH's 2016 timing attack mitigation: OpenSSH introduced dummy password hashing to equalize response times between invalid and valid usernames, preventing attackers from enumerating accounts based on how long authentication takes.
- Password length boundary: Musl libc caps password input at 256 bytes; passwords of 257-1,024 characters trigger the failure path in crypt(), which returns an asterisk that then matches the disabled-account marker in /etc/passwd or /etc/shadow.
- Required attack conditions: Exploitation needs musl libc, OpenSSH compiled without PAM, password authentication enabled, at least one account with a valid hash (to determine the hashing algorithm for dummy operations), and a target account with an asterisk password field.
- Affected platforms: Alpine Linux is the most prominent affected distribution, with official cloud images on AWS and Azure potentially vulnerable depending on OpenSSH configuration; embedded Linux systems using musl are also at risk.
Why it matters
This vulnerability highlights how security fixes can introduce new attack surfaces when interacting with alternative libc implementations, a concern for the growing Alpine Linux container and cloud ecosystem that deliberately chose musl for its smaller footprint. System administrators running Alpine or embedded musl systems should prioritize updating to OpenSSH 10.6p2 or immediately disable password authentication, as cloud-deployed instances may be directly exposed to remote exploitation.
What to do
- Update OpenSSH to version 10.6p2.
- Disable password authentication to mitigate the issue.
Original reference: www.theregister.com →