AI Weekly Malaysia

OpenSSH on musl-based Linux (Alpine, OpenWrt, Buildroot, Yocto, many Docker images) has since 2016 accepted any password longer than 256 characters for accounts whose password field is `*` — root, key-only deploy users, LDAP users, and Alpine's default AWS/Azure user. The chain: musl's `crypt()` returns `*` when SHA-512 crypt fails on >256-byte input, so sshd compares `*` to the stored `*` and authenticates. The write-up traces the `*` convention to 1980 Unix and the musl commits from 2012.

Why: If you run sshd inside an Alpine/musl container or appliance and rely on `*` to lock accounts, password auth is not actually disabled for >256-char inputs; set `PasswordAuthentication no` and `KbdInteractiveAuthentication no`, or patch/upgrade, and check whether your images even include openssh-server.

Tom's Hardware reports that chaining an OpenSSH flaw with a musl-libc flaw lets an attacker get in by typing any password longer than 256 characters, affecting Alpine Linux and other musl-based distributions. Emergency fixes for both OpenSSH and musl-libc were issued. The report does not give CVE IDs, affected version numbers, or patch commands.

Why: This is an authentication bypass, not a crash: if you run Alpine or OpenSSH on a musl system, the decision is whether to rebuild from a patched base image and re-check any sshd hosts you own now, rather than waiting for a scheduled patch window. Because the article names no versions or CVE, you cannot confirm from this text alone whether your image is affected — pull the actual advisory from your distro before assuming you are safe.

Alpine Linux published an advisory for an OpenSSH-server password authentication bypass: an attacker who can reach the SSH port can log in without a password by sending a 257–1024 byte password, provided the target account has a * password field and at least one account on the host has a $5$ or $6$ hash. It affects Alpine 3.16 through 3.24 and edge when openssh-server is built without PAM or openssh-server-pam uses UsePAM no, and PasswordAuthentication is yes. Fixed packages are in Alpine 3.21.10, 3.22.8, 3.23.8, and 3.24.4; upgrading alone does not replace the running daemon.

Why: If you run sshd on Alpine with the default PasswordAuthentication yes, any key-only account — root:* in the base image or a user created without a password — can become a login path for an attacker, so you need to restart sshd after apk upgrade or set PasswordAuthentication no and restart. The operational trap is that apk upgrade -U -a alone leaves the old daemon running.

The Hacker News headline reports that OpenSSH shipped an emergency fix for a flaw that lets unusually long passwords bypass SSH authentication specifically on Alpine Linux. Beyond the title, the supplied page text is almost entirely site navigation and boilerplate, so there are no affected version numbers, CVE identifier, patch release name, or exploit conditions to work from.

Why: Concretely, the one actionable fact is narrow: if you run SSH on Alpine Linux (common as a base image for small containers), an over-long password can reportedly authenticate without the correct credential, so patching OpenSSH on Alpine hosts is the specific action. Because the text gives no version range, no CVE, and no confirmation of whether the default Alpine sshd config is exposed, you cannot yet judge your own exposure from this item alone — check the actual advisory before assuming you are or aren't affected.