Hi Rich, > Date: 2026-11-09 08:56:50-0500 > From: Rich Felker > > 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 > > > > > > Hello list, > > > in case someone missed it: musl crypt() had an documented but > > > unexpected behavier that caused a lot of trouble. See: > > > 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 > --