[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261109131732.GM23438@brightrain.aerifal.cx>
Date: Mon, 9 Nov 2026 08:56:50 -0500
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx+linux-man@...nel.org>
Cc: Walter Harms <wharms@....de>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
libc-alpha@...rceware.org, musl@...ts.openwall.com,
~hallyn/shadow@...ts.sr.ht
Subject: Re: Re: RFC: how to document musl-crypt failure ?
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@....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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
