Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOp4FwTX2toQOWNM25oKT01ehwrQ=0-A4u74ay9Gtf-J-Wh_wQ@mail.gmail.com>
Date: Sat, 7 Nov 2026 08:24:49 +0400
From: Loganaden Velvindron <loganaden@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] [RFC] Harden against misuse of crypt

On Sat, 7 Nov 2026 at 03:18, Rich Felker <dalias@...c.org> wrote:
>
> On Sat, Nov 07, 2026 at 12:02:59AM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@...c.org> [2026-11-06 16:54:05 -0500]:
> > > This patch changes crypt to return "*0" instead of "*" as the "failure
> > > token" that will not match any password.
> > >
> > > Likewise, "*1" is used in place of "x" if the failure token would be
> > > identical to the input salt, but this case is presently unreachable.
> > > Since the existing DES path interprets characters outside the portable
> > > range as valid DES salt, passing a setting of "*0" will not produce
> > > "*1" but instead a DES-hashed password with "*0" as the salt. I don't
> > > see any problem with this -- "*0" should never appear in the
> > > passwd/shadow db anyway, and if it somehow did, crypt(pass,"*0") would
> > > still return something not-equal to "*0": "*0" followed by 11
> > > characters of DES hash.
> > >
> > > In any case, I put the "*1" code path in there in case anything ever
> > > changes with how we handle DES, to be sure crypt(pass,"*0") can never
> > > return "*0".
> > >
> > > Rich
> >
> > looks good,
> > but this commit has no reference to the analysis in
> > https://www.openwall.com/lists/musl/2026/11/06/7
> > i would add a link. or a note that the misuse was observed in
> > the wild motivating the change. and that "*0" has historical
> > precendent so broken callers are less likely.
>

>
> I still think that's the nicer behavior to move towards, but if there
> are still programs that will break, I'm rather hesitant to do it
> without a good transition period to get them fixed.
>
Rich, it's time to fix upstream software.

https://github.com/cyrusimap/cyrus-sasl/pull/905
https://github.com/InfrastructureServices/vsftpd/pull/9

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.