ThreatRoundup
CriticalBleepingComputer

An Overlong Password Opens Locked SSH Accounts on Alpine Linux

On musl-based Linux such as Alpine and OpenWrt, an oversized password can log in to accounts set to block password logins. Fixed in OpenSSH 10.6p2.

ThreatRoundup · · 2 min read

A newly disclosed bug in how OpenSSH behaves on musl-based Linux lets an attacker log in to accounts that were set up to refuse password logins, just by sending a password that’s far too long. Researcher Ozgun Kultekin, who calls it “*sshole,” says the flaw has been sitting there since 2016, according to BleepingComputer. It’s fixed in OpenSSH 10.6p2.

For defenders

What breaks: accounts locked against password login carry * instead of a hash in /etc/shadow. Since the 2016 fix for the CVE-2016-6210 username-enumeration bug, OpenSSH hashes the submitted password even for those accounts, to keep response times uniform. musl’s crypt() returns * when hashing fails, which it does for any password over 256 bytes. OpenSSH then compares * with the stored *, they match, and the login succeeds (T1078 (Valid Accounts)).

All of these must be true, per Kultekin:

  • OpenSSH on a musl system: Alpine Linux, OpenWrt, Buildroot or Yocto.
  • PAM authentication off (the default in Alpine’s openssh-server package) and SSH password authentication on.
  • At least one account with * as its hash, and another account with a real hash.

Worst case: Alpine’s official AWS and Azure images ship an affected alpine account with passwordless doas, so a bypass there can become root. glibc distributions (Debian, Ubuntu, Fedora) and any setup using PAM aren’t affected. Accounts with real password hashes can’t be bypassed this way.

Status: no CVE ID or CVSS score has been published yet, and there are no reports of exploitation in the wild so far. Fixed in OpenSSH 10.6p2; on Alpine run apk upgrade openssh. Stopgap: set PasswordAuthentication no in sshd_config and restart sshd.

Check for abuse: look in your SSH auth logs for successful password logins to accounts whose /etc/shadow entry is *. That combination shouldn’t be possible, so any hit is a red flag.

What it means for you

If you don’t run Linux servers, this one isn’t about you. If you do, it only matters on lightweight systems built on Alpine Linux (common in Docker containers and cloud images) or router firmware like OpenWrt, and only when SSH allows passwords. On those boxes, an account you thought was locked could be opened with a junk password.

Do this now

  1. Update OpenSSH to 10.6p2 on every Alpine, OpenWrt, Buildroot or Yocto system you run (apk upgrade openssh on Alpine).
  2. Turn off SSH password logins where you can (PasswordAuthentication no) and use SSH keys instead.
  3. On Alpine cloud VMs from the official AWS or Azure images, check the alpine account and its doas rights.
  4. Search SSH logs for password logins to locked accounts and treat any as a possible compromise.

More from the Roundup