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

[Alejandro Colomar <alx+linux-man@kernel.org>]

[-- 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 --]