[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <avHqKtsxQQDkZX90@devuan>
Date: Mon, 9 Nov 2026 16:50:58 +0100
From: Alejandro Colomar <alx+linux-man@...nel.org>
To: Rich Felker <dalias@...c.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 ?
Hi Rich,
> Date: 2026-11-09 08:56:50-0500
> From: Rich Felker <dalias@...c.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@....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>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
