[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261106230642.GA23438@brightrain.aerifal.cx>
Date: Fri, 6 Nov 2026 18:06:43 -0500
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] [RFC] Harden against misuse of crypt
On Fri, Nov 06, 2026 at 11:14:14PM +0100, Thorsten Glaser wrote:
> On Fri, 6 Nov 2026, Rich Felker wrote:
>
> >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".
>
> Something like this is necessary, as I’ve seen in older OpenSSH
> where it just passed "xx" as seed if it was shorter.
>
> FWIW I went with the equivalent of…
>
> (setting[0] == 'x') ? "**" : "x*";
>
> … in MirBSD yesternight, but it does now check the DES chars,
> so it’ll refuse "**" and "x*" as invalid seeds now, with the
> respective other returned.
>
> None of this fixes the OpenSSH bug (if a master.passwd(5) or
> shadow(5) entry has any of these values in the field), but it
> should be some defence-in-depth.
>
> But this gives some options as base for discussion: both the
> return values and whether DES should accept them (I’d probably
> argue that not, because that will return longer strings, which,
> should they ever end up in passwd/shadow, will pass OpenSSH’s
> new four-bytes-minimum string, so I’d rather the fallback strings
> be invalid for new hashing).
I have a transitional idea, to accept non-DES-characters if
strlen(setting)>2 (i.e. when validating an existing hash) but not when
strlen(setting)==2 (making a new hash). This would avoid breaking
anyone's passwords and locking them out while still allowing a clean
deterministic handling for generating new hashes that's not
"any random nonsense falls back to DES".
Rich
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.
