🐛🐧 The latest OpenSSH bug is actually a musl libc one!
Retards being retards, “Several Linux distributions have published a security advisory, letting users know that some systems running OpenSSH are vulnerable to a reliable remote login attack.”
Distrowatch believes that “The Alpine Linux project has an excellent summary, explanation, and workaround for the problem.”
While Alpine’s “Security advisory: openssh-server password authentication bypass” is certainly informative, I suspect most people missed that the bug (hence the vulnerability) exists only on systems that use musl’s crypt instead of glibc’s crypt!
From Alpine’s advisory:
musl’scrypt()returns the string*as an error indicator when the key is over 256 bytes long.*is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds.
It should have returned NULL! 😡
Danial Zahoor on FB:
OpenSSH rushed out version 10.6p2 to fix a critical auth bypass flaw. The bug hits Linux systems using the musl C library with PAM disabled, such as Alpine Linux.
Systems on glibc or PAM are not affected.
The bug is almost funny: on Alpine Linux, typing 257 to 1024 characters of anything into the password prompt gives you root.
OpenSSH's Damien Miller urged admins to disable password logins or SSH immediately. He added that long embargoes now mostly help attackers because AI agents rediscover these bugs within hours. Miller noted the root cause sits outside OpenSSH.
There is also a helpful screenshot.
Of course, “Setting PasswordAuthentication no in sshd_config completely blocks it because the server drops the connection before reaching the broken musl crypt code.”
However, as I mentioned, “Tbh the real culprit is the musl crypt() function that changed 2012 to return * instead of NULL for the passwords that get error, like too long.”
Also, password-based SSH authentication is not recommended. Public key authentication is the norm. Requiring both is also possible if you’re paranoid (AuthenticationMethods publickey,password). To avoid confusion, note that a private-key passphrase is not the same as requiring both authentication methods, as it only protects the key locally; it is not a second authentication factor verified by the SSH server.
For this particular bug, here’s a good summary of the conditions that need to be met for you to be fucked; I mean, vulnerable:
- The distro - It has to be Alpine, OpenWrt, or some other really obscure ones. Most distros use glibc.
- PAM has to be disabled.
- There has to be a local account with a SHA-256 or SHA-512 hash stored.
Circulez, y'a rien à voir !