Breaking Down the *sshole Exploit

AI-generated, human-reviewed.

The new “*sshole” OpenSSH bug made headlines for its severe security implications, but the reality is more nuanced than early reports suggested. According to this week’s Untitled Linux Show, the flaw can let users with a specific password setting log in with any long password—but in practice, only certain Linux distributions are affected, and default settings prevent exploitation for most users.

What Is the *sshole OpenSSH Vulnerability?

A new exploit, nicknamed “*sshole,” has surfaced in some Linux distributions running OpenSSH. On the show, experts explained that this vulnerability affects systems where user accounts have a password set as a single asterisk (“*”) in the passwd file, allowing attackers to log in with any password longer than 256 bytes.

However, the bug’s impact is limited to distributions using the MUSL C library, such as Alpine Linux, OpenWRT (only with custom SSHD installed), Buildroot, Yocto, and many minimal Docker images. These systems are commonly used for lightweight containers and embedded devices.

Which Systems Are Actually At Risk?

According to The Untitled Linux Show, the exploit is not a concern for most standard OpenSSH deployments. Instead, MUSL-based distributions, especially those set up for manual or nonstandard SSH configurations, are the target.

For instance, on OpenWRT, the default SSH daemon is Dropbear, which does not suffer from this flaw. Only systems where OpenSSH has been manually installed and configured are vulnerable. On Alpine Linux and similar systems, the vulnerability is only exploitable if root logins via password are allowed—something that’s disabled by default.

Key technical details:

• The bug results from an unexpected interaction between the MUSL crypt() implementation (which returns “*” instead of NULL on error) and the way OpenSSH checks password hashes.
• When a long password is provided, crypt() returns “”. If the user account’s password field in /etc/passwd also contains “”, OpenSSH deems it a match and grants access.
• Default configurations in almost all major distros prevent the attack vector from being open.

How Did This Happen?

The vulnerability is an unintended side effect of how password authentication logic interacts between OpenSSH and the MUSL library. The show’s discussion explored the evolution of UNIX password handling: Once, passwords were stored in plain text. Modern systems instead store hashed values or a placeholder representing accounts with no usable password.

MUSL’s crypt() function never returns NULL (for backward compatibility and bug prevention), but returns “*” on error—ironically, the same symbol used in /etc/passwd to signal “no password set.” OpenSSH, expecting a NULL on hash failure, matches the two, inadvertently allowing access. This subtle logic mismatch underscores the complexity of security in modern systems, especially when combining software components with slightly different interpretations of standards.

Practical Impact for Linux Admins

On The Untitled Linux Show, participants emphasized most users and sysadmins don’t need to panic, especially those running mainstream Linux distributions. The window for actual exploitation is narrow:

• You must be running a vulnerable version of OpenSSH on a MUSL-based distro.
• The vulnerable account must have a password field of “*”.
• You must have non-default configurations allowing root login via password.

Admins are advised to review their SSH configurations, check which SSH daemon is installed (especially on systems like OpenWRT), and apply patches as they become available for systems where MUSL and OpenSSH intersect.

The *sshole Picture

• The *sshole bug does not affect most Linux users running default configurations.
• Systems based on Alpine, OpenWRT (with manual OpenSSH), and similar minimal distros are at theoretical risk, but only in specific, non-default scenarios.
• Default Dropbear SSH on OpenWRT and root login restrictions on Alpine neutralize this flaw for most setups.
• Issue arises due to subtle differences in how MUSL’s crypt() and OpenSSH handle password verification logic, especially with error returns.
• Vulnerability requires both code update and careful configuration review to close all possible gaps.

The Bottom Line

While the *sshole OpenSSH vulnerability sounds dire, The Untitled Linux Show demonstrates that the risk is limited in scope. Most admins and home users with mainstream distros or default settings are protected. Users running MUSL-based minimal systems with custom configurations should verify their SSH setups and stay alert for upstream patches.

Listen and keep your systems secure by understanding both the hype and the real technical impact of new vulnerabilities.

Subscribe for more expert Linux coverage:
https://twit.tv/shows/untitled-linux-show/episodes/278