HN
Today

Sshole

A decade-long SSH vulnerability has been unearthed in Musl-based Linux distributions, where accounts marked 'password-disabled' could be accessed with any password longer than 256 characters. This deep technical dive meticulously reconstructs how subtle changes in crypt() behavior and OpenSSH's salt handling created a critical, widespread security hole. The story highlights the terrifying fragility of complex systems and the surprising ways seemingly minor decisions can compound into major compromises.

19
Score
1
Comments
#1
Highest Rank
4h
on Front Page
First Seen
Nov 5, 12:00 PM
Last Seen
Nov 5, 3:00 PM
Rank Over Time
1111

The Lowdown

For a decade, a critical vulnerability lurked in Musl-based Linux systems, including popular distributions like Alpine Linux and OpenWrt, allowing attackers to log into accounts that were explicitly configured not to accept passwords. By simply providing any password longer than 256 characters, users could bypass security on accounts marked with a * in /etc/shadow, such as the root user on Alpine cloud images or key-only deploy users. This elaborate security flaw is a testament to how complex interactions between seemingly disparate system components can lead to profound and unexpected compromises.

  • The /etc/passwd Star (1980): Historically, a * in the password field of /etc/passwd signified an account that could not be logged into with a password. This convention persisted with /etc/shadow.
  • Musl's crypt() Change (2012): The Musl C library, used by Alpine, modified its crypt() function. Instead of returning NULL for invalid inputs (which often caused programs to crash), it began returning a literal * string, intended to be unmatchable, to indicate failure.
  • Password Length Limit (2012): Shortly after, Musl implemented a KEY_MAX limit of 256 bytes for SHA512 crypt() to prevent Denial-of-Service attacks from excessively long passwords. Any password exceeding this length would cause crypt() to fail and, consequently, return *.
  • OpenSSH's Timing Attack Fix (2016): To mitigate timing-based user enumeration attacks (CVE-2016-6210), OpenSSH was updated to "borrow" a salt from another user and hash the provided password, even for invalid users or accounts with no real hash (like *), ensuring consistent response times.
  • Alpine's /etc/shadow Root (2019-2022): Alpine Linux, in its efforts to enable SSH key logins for root without PAM, switched the root user's password field from ! (which disables all password logins, even via keys without PAM) to *, unknowingly making it susceptible to this specific flaw.
  • The Confluence of Bugs: When an attacker supplied a password longer than 256 characters to an OpenSSH server on a Musl-based system, Musl's crypt() would return *. If the target account's /etc/shadow entry also contained * (signifying "no password"), OpenSSH's logic, attempting to normalize timing, would compare * to * and mistakenly grant access.
  • Discovery: The author systematically tested various OpenSSH builds and configurations, finding that only Musl builds without PAM were vulnerable, leading to the intricate uncovering of this chain of events.
  • Impact and Resolution: Affected systems include Alpine Linux, OpenWrt, Buildroot, and Yocto running sshd without PAM, where password logins are enabled, and * accounts exist alongside those with actual passwords. The fix is to update OpenSSH to 10.6p2 or disable password authentication. The presence of root@your-box entries in authentication logs for an account with no password indicates a potential compromise.

This deep dive into an obscure bug, rooted in seemingly minor design choices across different projects and spanning over a decade, serves as a stark reminder of the hidden complexities in system security. It underscores the critical need for vigilance and thorough analysis even in the most fundamental components of our software infrastructure.