EN PT-BR
← Voltar ao feed
high

OpenSSH on musl Linux: oversized passwords log into password-less accounts (sshole flaw, fixed in 10.6p2)

1 fonte(s) · 1 atualização(ões) · publicado 10/11/2026 09:02 · coletado há 2 horas

Bruce Schneier's blog reports a newly disclosed flaw in OpenSSH on musl-based Linux, nicknamed “sshole”, that lets an attacker log in to accounts configured to refuse password authentication by submitting a password longer than 256 bytes (schneier.com). The researcher Ozgun Kultekin traces it to musl libc behaviour dating from 2012, when failed crypt() calls began returning an unmatchable “” hash, so an account whose password field is “*” matches the attacker's input (sshhole.com). Alpine Linux and other musl systems such as OpenWrt, Buildroot and Yocto are affected, but only when sshd runs without PAM and password logins are still enabled, which is the default (sshhole.com). The most serious case is Alpine's official AWS and Azure images, where the default alpine user has passwordless doas and therefore a path to root (sshhole.com). The researcher says the fix shipped in OpenSSH 10.6p2 on 2026-11-05 and that Alpine packages are already updated (github.com/oz9un/sshole). No CVE for the new flaw and no in-the-wild exploitation appear in the sources opened, and the researcher writes that, as far as anyone knows, nobody noticed it before, so criticity is high rather than critical.

Entenda a falha

A vulnerabilidade

Flaw nicknamed "sshole" in OpenSSH sshd on musl libc systems built without PAM (Alpine Linux, OpenWrt, Buildroot, Yocto), with no CVE assigned. An unauthenticated remote attacker who can reach sshd can log in to an account whose shadow password field is only "*" (key-only users, LDAP users, root on Alpine) by submitting a password longer than 256 bytes. It needs password authentication enabled, which is the default. The worst case is Alpine's official AWS and Azure images, where the default alpine user has passwordless doas, giving a path to root. The researcher says it is fixed in OpenSSH 10.6p2 (2026-11-05); his upstream patch for older releases applies from 7.3p1.

Como funciona

A login attempt arrives at sshd using password authentication for an account whose shadow entry is "*", meaning it should never accept a password. sshd hashes the submitted password with crypt() from musl and compares the result to the stored field. When the password is longer than 256 bytes, musl's SHA-512 crypt support refuses it and returns "*" as the result. sshd then compares "*" with the stored "*", sees a match and treats the password as correct, so the login succeeds.

Por que é vulnerável

The bug comes from combining three behaviours. In 2012 musl changed crypt() to return "*" on failure instead of NULL, and weeks later the SHA-512 crypt support rejected passwords above 256 bytes by returning that same "*" (musl commits b3c4cc12 and 88bf5a8a, per the researcher). The failure value is identical to the "locked account" marker, and sshd without PAM does not tell the two apart. The researcher says nobody appears to have noticed it before. The fix, in OpenSSH 10.6p2, avoids this password authentication bypass; the articles do not detail the code change.

Onde está

The repository github.com/oz9un/sshole names its upstream patch 4353fdc43-avoid-password-authn-bypass.patch; the fix commit itself was not examined and no file or function is named.

Como foi descoberta

The researcher Ozgun Kultekin disclosed it, with a write-up on sshhole.com and a repository at github.com/oz9un/sshole. His tests covered about 17,600 logins across glibc, musl, PAM and non-PAM sshd builds, and only musl without PAM accepted the wrong password. Bruce Schneier's blog relayed the disclosure on 2026-11-10. The sources show no in-the-wild exploitation.

Explicação gerada por IA a partir da matéria e dos artigos, em 10/11/2026 10:27.

Detalhes técnicos

The flaw combines three parts. In 2012 musl stopped returning NULL from crypt() on failure and returned “” instead, and the SHA-512 crypt support added weeks later rejects passwords above 256 bytes by returning that same “” (sshhole.com, citing musl commits b3c4cc12 and 88bf5a8a). A “” stored in /etc/shadow is meant to never match any password, so an oversized password that produces “” compares equal to it (sshhole.com). The researcher's tests ran about 17,600 logins across glibc, musl, PAM and non-PAM sshd builds, and only musl without PAM accepted the wrong password (sshhole.com).

Prerequisites are: sshd built on musl without PAM (Alpine's openssh-server does not use PAM by default); password authentication enabled (the default); and at least one account whose shadow field is only “*”, such as a key-only user, an LDAP user or root on Alpine (sshhole.com). The researcher's test page treats oversized as 257 to 1024 characters (sshhole.com). The sshhole.com page recalls CVE-2019-5021 (Alpine images shipped with no root password) and CVE-2016-6210 (timing-based user enumeration) as background only (sshhole.com). The news links in the Schneier post (BleepingComputer, Ars Technica) could not be opened and are not used here.

Remediação

  • Upgrade OpenSSH to 10.6p2; on Alpine, run apk upgrade openssh (github.com/oz9un/sshole, sshhole.com). The repository states that its upstream patch for older releases applies from 7.3p1 onward (github.com/oz9un/sshole).
  • If an upgrade cannot be done yet, set PasswordAuthentication to no in sshd (sshhole.com).
  • Run the check script published in github.com/oz9un/sshole to see whether a host has the required configuration.
  • Review authentication logs for successful logins from accounts that have no password, and treat any hit as a compromise.
  • The fix commit and its pull request were not opened in this research. The repository names its upstream patch 4353fdc43-avoid-password-authn-bypass.patch (github.com/oz9un/sshole), and the OpenSSH release notes were not reachable.

Linha do tempo

  1. schneier.com ↗ · pub. 10/11/2026 09:02 · coletado 10/11 10:00 primeiro registro

    OpenSSH on musl Linux: oversized passwords log into password-less accounts (sshole flaw, fixed in 10.6p2)

    ler a análise desta fonte

    Bruce Schneier's blog reports a newly disclosed flaw in OpenSSH on musl-based Linux, nicknamed “sshole”, that lets an attacker log in to accounts configured to refuse password authentication by submitting a password longer than 256 bytes (schneier.com). The researcher Ozgun Kultekin traces it to musl libc behaviour dating from 2012, when failed crypt() calls began returning an unmatchable “” hash, so an account whose password field is “*” matches the attacker's input (sshhole.com). Alpine Linux and other musl systems such as OpenWrt, Buildroot and Yocto are affected, but only when sshd runs without PAM and password logins are still enabled, which is the default (sshhole.com). The most serious case is Alpine's official AWS and Azure images, where the default alpine user has passwordless doas and therefore a path to root (sshhole.com). The researcher says the fix shipped in OpenSSH 10.6p2 on 2026-11-05 and that Alpine packages are already updated (github.com/oz9un/sshole). No CVE for the new flaw and no in-the-wild exploitation appear in the sources opened, and the researcher writes that, as far as anyone knows, nobody noticed it before, so criticity is high rather than critical.

    Technical Details

    The flaw combines three parts. In 2012 musl stopped returning NULL from crypt() on failure and returned “” instead, and the SHA-512 crypt support added weeks later rejects passwords above 256 bytes by returning that same “” (sshhole.com, citing musl commits b3c4cc12 and 88bf5a8a). A “” stored in /etc/shadow is meant to never match any password, so an oversized password that produces “” compares equal to it (sshhole.com). The researcher's tests ran about 17,600 logins across glibc, musl, PAM and non-PAM sshd builds, and only musl without PAM accepted the wrong password (sshhole.com).

    Prerequisites are: sshd built on musl without PAM (Alpine's openssh-server does not use PAM by default); password authentication enabled (the default); and at least one account whose shadow field is only “*”, such as a key-only user, an LDAP user or root on Alpine (sshhole.com). The researcher's test page treats oversized as 257 to 1024 characters (sshhole.com). The sshhole.com page recalls CVE-2019-5021 (Alpine images shipped with no root password) and CVE-2016-6210 (timing-based user enumeration) as background only (sshhole.com). The news links in the Schneier post (BleepingComputer, Ars Technica) could not be opened and are not used here.

    Remediation

    • Upgrade OpenSSH to 10.6p2; on Alpine, run apk upgrade openssh (github.com/oz9un/sshole, sshhole.com). The repository states that its upstream patch for older releases applies from 7.3p1 onward (github.com/oz9un/sshole).
    • If an upgrade cannot be done yet, set PasswordAuthentication to no in sshd (sshhole.com).
    • Run the check script published in github.com/oz9un/sshole to see whether a host has the required configuration.
    • Review authentication logs for successful logins from accounts that have no password, and treat any hit as a compromise.
    • The fix commit and its pull request were not opened in this research. The repository names its upstream patch 4353fdc43-avoid-password-authn-bypass.patch (github.com/oz9un/sshole), and the OpenSSH release notes were not reachable.