SSHole — a vulnerability that allows password-less SSH connections on systems with Musl

The OpenSSH developers have released an emergency update for OpenSSH 10.6p2, which adds protection against a critical vulnerability (CVE not assigned), code-named 'SSHole', that allows authentication bypass. In systems with the Musl library, the vulnerability allows connecting to a user without a password by entering any password longer than 256 characters. The issue affects Linux distributions using the standard musl library but not utilizing PAM (Pluggable Authentication Modules), such as OpenWRT, Alpine, Buildroot, and Yocto. A particular concern is that password login is often blocked for the root user, which can let anyone connect remotely with admin rights.

The vulnerability-causing bug is not in the OpenSSH code but is exploited through sshd. Given the seriousness of the issue in version OpenSSH 10.6p2, a workaround to block the vulnerability has been proposed. Owners of affected systems are advised not to wait for updates but to immediately disable password authentication using the parameter 'PasswordAuthentication no' in /etc/ssh/sshd_config or to completely disable SSH.

The problem does not occur in systems other than Linux, and in Linux environments based on glibc, as well as in systems using PAM for password authentication. A fix is already available in Alpine and OpenWRT.

The vulnerability is related to incorrect interaction between OpenSSH and the crypt() function from musl. To protect against determining the existence of users by analyzing request processing time differences, since 2016 OpenSSH uses the standard password checking procedure when verifying accounts without passwords: it calls the function 'crypt(passed password, salt)' with the salt of another user who has a valid password hash, and then compares the hash returned by crypt with the value in the password hash field.

However, in musl, the crypt() function for SHA-512 hashes returns the character '*', if the length of the passed password exceeds 256 bytes (the limit was introduced in 2012 to protect against DoS attacks, as larger values place a significant load on the CPU). The same character is used in the password hash field in '/etc/shadow' to denote accounts for which password authentication is blocked.

As a result, an attacker with the ability to connect to an SSH server can connect to any account where the password field in '/etc/shadow' is marked with an asterisk '*', by sending a string between 257 to 1024 bytes long. This issue affects numerous existing Docker images built using Alpine Linux, as well as standard Alpine images for cloud systems AWS and Azure, where the root user has an asterisk '*' instead of a password hash.

Notably, initially in official Docker images using Alpine since 2015, the root password was set to empty, and after this fact was revealed, an exclamation mark '!' was used instead of the password hash. However, its presence blocked login via SSH keys, so starting from 2022, the character for blocking password logins was changed to an asterisk '*'.

Source: opennet.ru