Alpine Linux passwordless SSH flaw impacts widely used devices

No password needed. An Alpine Linux passwordless SSH flaw, rooted in a vulnerability that has existed for a decade, is allowing attackers to log into systems without needing a password. It's a critical security oversight. This affects devices running specific configurations of Alpine Linux, and potentially other distributions. And the core issue lies in the complex interplay between OpenSSH, the widely adopted library for SSH connections, and musl, a lightweight alternative to the standard libc library which Alpine uniquely employs.

Conditions must align. The system needs musl and OpenSSH. It can't use PAM, those modules which usually handle user authentication. And critically, two more things are required before unauthorized access becomes possible. Specifically, the compromised device must possess at least one user account whose password hash was generated using either the SHA256 or SHA512 functions, a common hashing algorithm choice. That target account must also be deliberately set up to be passwordless. This is clearly shown by a single asterisk, "*", in its password field within the `/etc/shadow` file, a common setup for accounts that rely on certificate-based authentication rather than standard passwords.

Conditions align. Attackers gain access. It's simple: supply over 256 characters in the SSH password field. This peculiar interaction exploits the system's reliance on SHA256 or SHA512 hashes, as security firm Checkpoint's researchers explained, noting that the `sshd` process borrows that account's salt from these specific hash types, a critical component without which the attack won't succeed. Checkpoint's testing confirmed the targeted account must be active, not merely holding a hash, for the exploit to work. Default settings generally protect root accounts by prohibiting direct password logins. But any accessible account with `doas` or `sudo` privileges could still be used to escalate to root access, amplifying the potential damage.

The Mechanics of the Exploit

The "*sshole" vulnerability poses a grave risk. Dubbed by its discoverer, this flaw, despite its specific prerequisites, threatens a vast number of systems, and the sheer ubiquity of Alpine Linux amplifies the concern significantly. Its reach is staggering. For example, the base image for Alpine on Docker Hub alone has accumulated over one billion downloads. And it's a favored choice for embedded devices like routers, smart TVs, and industrial controllers. Many of these devices simply don't get updates. They're left perpetually exposed.

Beyond embedded systems, Alpine has found increasing adoption in desktops, servers, and especially container images, broadening its attack surface considerably. Security firm Detectify has publicly available data. It indicates approximately 22 million systems globally have SSH open on port 22. This comes via Shodan. But they're not all exploitable. While only a fraction of these systems will meet the precise conditions for exploitation, the ease and speed with which an attacker can test for vulnerability mean that identifying susceptible devices requires minimal effort or time.

• OpenSSH must be in use with musl.
• PAM (pluggable authentication modules) must not be configured.
• At least one user account must have a password hashed with SHA256 or SHA512.
• The target account must be explicitly passwordless, marked with a "*" in `/etc/shadow`.
• The targeted account must be active.

Differing Views on the Root Cause

Its origin sparks debate. Developers can't agree on the *sshole vulnerability's precise source. OpenSSH released an update addressing the issue, stating they "consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there," indicating their software acts as the attack's vector. So, the underlying flaw might reside elsewhere in the system's components.

Rich Felker disagreed. He's a musl developer, you see. Felker stated plainly, "This isn't a bug in musl, it's just an erroneous use by the caller." He further indicated that musl developers had been considering changes to the underlying mechanism for quite some time, intending to implement them in an upcoming release, which suggested the issue might very well originate from how other software interacts with musl, rather than from a defect intrinsically present within musl itself. This ongoing debate illuminates the intricate challenges involved in pinpointing and rectifying deeply embedded vulnerabilities within interconnected software ecosystems.

Alpine maintainers sounded an alarm. An attacker who accesses your SSH port can log in. No password is needed. And they stated emphatically that this method allows direct system entry, requiring just one connection, and it's guaranteed to work every single time without needing retries.

Widespread Impact Across Devices

Alpine's SSH flaw spreads. It's not just Alpine's direct installations. But while OpenWRT was cited as affected by the vulnerability's discoverer, that operating system typically defaults to using the Dropbear package for SSH connections, not OpenSSH. However, users who have manually installed OpenSSH on OpenWRT, following available instructions, could still find themselves at risk. Buildroot and Yocto were also named as potentially vulnerable. These claims aren't confirmed yet.

Exploitation is child's play. It only needs one connection, no retries required at all, a chillingly simple path for attackers seeking to compromise systems that often manage vital operations and personal data, underscoring the immediate necessity for swift safeguards. This is particularly important because Alpine Linux is widely used in critical infrastructure and many consumer devices. If these systems aren't patched, millions could be left open to unauthorized access, possibly leading to serious data breaches, full system takeovers, or even widespread network intrusions. Legacy embedded devices, in particular, are at risk, as they might never get the needed updates. It's worrying.

Immediate Action Required

Its origin remains uncertain. Yet, the exact source of this vulnerability and precisely which other packages might be compromised are still unknown, though the recommended course of action is undeniably clear and requires immediate attention from system administrators. If you're running a Linux system that relies on both musl and OpenSSH, you absolutely must investigate your configuration for exposure to this alarming flaw. Alpine and OpenSSH released updates. Installing these patches on all affected systems is the most critical step to mitigate the risk associated with this Alpine Linux passwordless SSH vulnerability.

No CVE yet. Its threat is undeniable. System administrators must prioritize reviewing their `/etc/shadow` files for passwordless accounts, ensuring all necessary updates from Alpine and OpenSSH are applied without delay. Taking proactive security measures is especially important, particularly for widely used base images and embedded systems, to safeguard against these easily exploitable flaws.