OpenSSH flaw allows unauthorized access on musl-based Linux systems

Security researcher Ozgun Kultekin has disclosed a critical OpenSSH vulnerability, dubbed '*sshole', which allows attackers to log in to accounts with password authentication disabled. The issue affects specific Linux distributions using the musl C library.

• Vulnerability impacts Alpine Linux, OpenWrt, Buildroot, and Yocto.
• Attackers use oversized passwords to exploit how OpenSSH handles authentication errors.
• The flaw has existed since 2016 due to a previous security patch.
• Glibc-based systems like Ubuntu or Debian are not affected.

Technical breakdown of the flaw The vulnerability stems from a 2016 patch designed to prevent username enumeration (CVE-2016-6210). To prevent attackers from timing responses to identify valid usernames, OpenSSH was updated to perform password hashing even when an account is locked (denoted by an asterisk in /etc/shadow). The musl C library's crypt() function behaves differently than glibc: when password hashing fails—such as when an input exceeds 256 bytes—it returns an asterisk. OpenSSH compares this returned asterisk with the user's password field. If it matches, the system incorrectly grants access, bypassing the intended authentication block.

Impact on Cloud and Container Environments The researcher highlights that Alpine Linux's official cloud images for AWS and Azure are particularly vulnerable because they include a default 'alpine' account with 'doas' privileges. An attacker could potentially gain root access through this flaw. It is important to note that only systems using the musl C library and lacking PAM authentication are susceptible. If your infrastructure relies on standard distributions like Debian, Ubuntu, or Fedora, they remain secure against this specific exploit vector.

Remediation and Mitigation OpenSSH 10.6p2 includes the necessary fix. Users on affected systems should update immediately using 'apk upgrade openssh'. If patching is not feasible, administrators can effectively mitigate the risk by setting 'PasswordAuthentication no' in the sshd_config file and restarting the SSH service. Administrators are also advised to audit authentication logs for successful password-based logins on accounts that should have password authentication disabled. Cross-referencing these logs with /etc/shadow file contents can identify if an account has been compromised.

Significance for DevOps and SecOps For teams utilizing containerized environments and lightweight Linux distributions, this vulnerability serves as a stark reminder of the security implications of low-level library differences. While musl offers efficiency, its nuances can create unexpected security gaps when interacting with established software like OpenSSH. Maintaining a robust patch management strategy and adhering to the principle of least privilege—especially for default cloud accounts—is essential for modern infrastructure protection.