[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <719CFC9E-9E89-473A-A7CB-CB1BE30143EE@gmail.com>
Date: Tue, 10 Nov 2026 03:31:08 +0900
From: Seo Suchan <tjtncks@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Re: RFC: how to document musl-crypt failure ?
About musl, as it doesn't error at invalid hash but fall back to des. so client using it should check returned hash is expected length of that algorithm when you make new password: it may just silently interpret it as des hash request because it didn't understand hash algorithm. (Ex: busybox passwd with yestcrypt option that musl doesn't support
On 2026년 11월 10일 오전 12시 50분 58초 GMT+09:00, Alejandro Colomar <alx+linux-man@...nel.org> 작성함:
>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>
Content of type "text/html" skipped
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.
