RFC: how to document musl-crypt failure ?

RFC: how to document musl-crypt failure ?

[Walter Harms]

Hello list,
in case someone missed it: musl crypt() had an documented but unexpected behavier that caused
a lot of trouble. See: https://news.ycombinator.com/item?id=50377221   SSHHole.com  CVE-2026-123158

Normaly i would step over it but in this special case ... it would like to start a discussion if we should mention
that in a note to crypt(). Perhaps recommending an additional check for '*' ? I am not sure but this is a very special case ...

CU 

Re: RFC: how to document musl-crypt failure ?

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Hi Walter,

> Date: 2026-11-09 08:59:19+0000
> From: Walter Harms <wharms@bfs.de>
>
> Hello list,
> in case someone missed it: musl crypt() had an documented but
> unexpected behavier that caused a lot of trouble.  See:
> <https://news.ycombinator.com/item?id=50377221>   SSHHole.com  CVE-2026-123158

Indeed, I also wondered if we should change something in the
documentation after it happened.  Unfortunately, the bug has been
treated with some secrecy in the first days (reasonable), so I couldn't
really understand what went wrong.

I've CCed Rich and also musl and glibc, since they probably want to
comment.  I've also CCd shadow-utils.

> Normaly i would step over it but in this special case ... it would
> like to start a discussion if we should mention that in a note to
> crypt().

Thanks!

> Perhaps recommending an additional check for '*' ?  I am not sure but
> this is a very special case ...

Rich, now that some time has passed and I guess everyone has a patched
SSH, would you mind clarifying what happened, and what should be
documented about it?


Have a lovely day!
Alex

> CU 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: RFC: how to document musl-crypt failure ?

[Andreas Schwab]

On Nov 09 2026, Alejandro Colomar wrote:

> I've CCed Rich and also musl and glibc, since they probably want to
> comment.  I've also CCd shadow-utils.

libcrypt is no longer part of glibc, it is now provided by libxcrypt.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de

Re: RFC: how to document musl-crypt failure ?

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> On Nov 09 2026, Alejandro Colomar wrote:
>
>> I've CCed Rich and also musl and glibc, since they probably want to
>> comment.  I've also CCd shadow-utils.
>
> libcrypt is no longer part of glibc, it is now provided by libxcrypt.

Indeed. But while we're here..

For libxcypt, it's determined by the configure option:
--disable-error-tokens. By default, error tokens are enabled.

I've switched Gentoo to use --disable-*. Fedora already did many years
ago so package failures should be smoked out by now:
* https://src.fedoraproject.org/rpms/libxcrypt/c/853ed305cd53c67bb2827dce78b889c8d187e1e0?branch=rawhide
* https://bugzilla.redhat.com/show_bug.cgi?id=1611784

Debian uses the libxcrypt default. I didn't check other distros yet.

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: [musl] Re: RFC: how to document musl-crypt failure ?

[Rich Felker]

On Mon, Nov 09, 2026 at 11:10:56AM +0100, Alejandro Colomar wrote:
> Hi Walter,
> 
> > Date: 2026-11-09 08:59:19+0000
> > From: Walter Harms <wharms@bfs.de>
> >
> > Hello list,
> > in case someone missed it: musl crypt() had an documented but
> > unexpected behavier that caused a lot of trouble.  See:
> > <https://news.ycombinator.com/item?id=50377221>   SSHHole.com  CVE-2026-123158
> 
> Indeed, I also wondered if we should change something in the
> documentation after it happened.  Unfortunately, the bug has been
> treated with some secrecy in the first days (reasonable), so I couldn't
> really understand what went wrong.
> 
> I've CCed Rich and also musl and glibc, since they probably want to
> comment.  I've also CCd shadow-utils.
> 
> > Normaly i would step over it but in this special case ... it would
> > like to start a discussion if we should mention that in a note to
> > crypt().
> 
> Thanks!
> 
> > Perhaps recommending an additional check for '*' ?  I am not sure but
> > this is a very special case ...
> 
> Rich, now that some time has passed and I guess everyone has a patched
> SSH, would you mind clarifying what happened, and what should be
> documented about it?

Have you seen my full analysis on the musl list?

https://www.openwall.com/lists/musl/2026/11/06/7

The correct usage of crypt for password authentication is asserting
that, if P is the candidate password and H is the account password
"hash", strcmp(crypt(P,H),H)==0. Allowing the user in without checking
that is potentially a password-authentication-bypass bug.

I put "hash" in quotation marks because it might not be an actual
hash; it can be a string chosen by the tooling or a user manually
editing the passwd/shadow files to produce something unmatchable. So
an application should not be making assumptions about its form.

Through at least 1.2.6, musl uses failure tokens "*" and "x" for cases
where the password should never match. These include unsupported
password length (for hash types that need to restrict it) and
unsupported or invalid setting/salt strings.

It isn't decided yet, but 1.2.7 will probably switch to using failure
tokens matching libxcrypt's ("*0" and "*1") which are slightly safer
against some forms of misuse by the caller. Future versions may drop
failure tokens entirely and switch to treating these conditions as
errors (returning null).

I would not document future behavior, and would document existing
behavior only as an implementation detail, not an application-facing
contract. The only contract with the application is that crypt(P,H)
will never return a string identical to H except on valid password (in
the absence of theoretical hash collisions) regardless of the validity
of P and H.

Rich

Re: [musl] Re: RFC: how to document musl-crypt failure ?

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]

Hi Rich,

> Date: 2026-11-09 08:56:50-0500
> From: Rich Felker <dalias@libc.org>
>
> On Mon, Nov 09, 2026 at 11:10:56AM +0100, Alejandro Colomar wrote:
> > Hi Walter,
> > 
> > > Date: 2026-11-09 08:59:19+0000
> > > From: Walter Harms <wharms@bfs.de>
> > >
> > > Hello list,
> > > in case someone missed it: musl crypt() had an documented but
> > > unexpected behavier that caused a lot of trouble.  See:
> > > <https://news.ycombinator.com/item?id=50377221>   SSHHole.com  CVE-2026-123158
> > 
> > Indeed, I also wondered if we should change something in the
> > documentation after it happened.  Unfortunately, the bug has been
> > treated with some secrecy in the first days (reasonable), so I couldn't
> > really understand what went wrong.
> > 
> > I've CCed Rich and also musl and glibc, since they probably want to
> > comment.  I've also CCd shadow-utils.
> > 
> > > Normaly i would step over it but in this special case ... it would
> > > like to start a discussion if we should mention that in a note to
> > > crypt().
> > 
> > Thanks!
> > 
> > > Perhaps recommending an additional check for '*' ?  I am not sure but
> > > this is a very special case ...
> > 
> > Rich, now that some time has passed and I guess everyone has a patched
> > SSH, would you mind clarifying what happened, and what should be
> > documented about it?
> 
> Have you seen my full analysis on the musl list?
> 
> https://www.openwall.com/lists/musl/2026/11/06/7

Not before, but thanks!  Now I have read it.

I agree with the suggestion of using null+errno in the future, BTW.
FWIW, shadow-utils already handles well a null pointer.

> The correct usage of crypt for password authentication is asserting
> that, if P is the candidate password and H is the account password
> "hash", strcmp(crypt(P,H),H)==0. Allowing the user in without checking
> that is potentially a password-authentication-bypass bug.
> 
> I put "hash" in quotation marks because it might not be an actual
> hash; it can be a string chosen by the tooling or a user manually
> editing the passwd/shadow files to produce something unmatchable. So
> an application should not be making assumptions about its form.
> 
> Through at least 1.2.6, musl uses failure tokens "*" and "x" for cases
> where the password should never match. These include unsupported
> password length (for hash types that need to restrict it) and
> unsupported or invalid setting/salt strings.
> 
> It isn't decided yet, but 1.2.7 will probably switch to using failure
> tokens matching libxcrypt's ("*0" and "*1") which are slightly safer
> against some forms of misuse by the caller.

Ok.  Please CC linux-man@ when that happens.

> Future versions may drop
> failure tokens entirely and switch to treating these conditions as
> errors (returning null).

+1.  Again, please CC linux-man@ when that happens.

> I would not document future behavior, and would document existing
> behavior only as an implementation detail, not an application-facing
> contract. The only contract with the application is that crypt(P,H)
> will never return a string identical to H except on valid password (in
> the absence of theoretical hash collisions) regardless of the validity
> of P and H.

Okay.  Thank you very much!  I'll work on a patch, and CC you when it's
ready.


Have a lovely day!
Alex

> 
> Rich
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]